Ok, like I stated before if you have only a-law (8) or mu-law (0) set then the output you see in the 200ok SDP is correct:
v=0
o=Dialogic_SIP_CCLIB 0 1 IN IP4 172.18.180.10
s=Dialogic_SIP_CCLIB
i=session information
c=IN IP4 172.18.180.10
t=0 0
m=audio 49152 RTP/AVP 8
a=ptime:20
There will not be a= line as per specification as its stated in the 8 (for a-law) only needs to be present in the m= line.
Jeff
I take it by GSM you are referring to G.722 in this case? If so, then that requires a separate license feature which needs to be added in this case.
Jeff
Yes that output is what we get when we let the GC library to handle OPTIONS request. As soon as we switch the handling to our custom implementation we get this
Device: [DEVICE: iptB1]gcValue: 44; gcMsg: Invalid parameter; ccLibId: 8; ccLibN
ame: GC_H3R_LIB; ccValue: 5; ccMsg: IPERR_BAD_PARAM; additionalInfo:
So here is how we do it and so far we just try to simulate the default output but from custom implementation.
If you see anything suspicious please let us know.
Best Regards.
IP_VIRTBOARD virtBoards[1];
/* Other code */
virtBoards[0].E_SIP_OPTIONS_Access = ENUM_Enabled;
Then in the device event handler function:
Approach 1 - setup IP_CAPABILITY
GC_PARM_BLKP paramBlock = NULL;
IP_CAPABILITY *txCap = new IP_CAPABILITY;
ZeroMemory(txCap, sizeof(IP_CAPABILITY));
txCap->capability = CODEC_AUDIO_G711ALAW64K;
txCap->direction = IP_CAP_DIR_LCLTRANSMIT;
txCap->type = GCCAPTYPE_AUDIO;
txCap->extra.audio.frames_per_pkt = 20;
txCap->extra.audio.VAD = GCPV_DISABLE;
IP_CAPABILITY *rxCap = new IP_CAPABILITY;
ZeroMemory(rxCap, sizeof(IP_CAPABILITY));
rxCap->capability = CODEC_AUDIO_G711ALAW64K;
rxCap->direction = IP_CAP_DIR_LCLTRANSMIT;
rxCap->type = GCCAPTYPE_AUDIO;
rxCap->extra.audio.frames_per_pkt = 20;
rxCap->extra.audio.VAD = GCPV_DISABLE;
gc_util_insert_parm_ref_ex(¶mBlock,
GCSET_CHAN_CAPABILITY, IPPARM_LOCAL_CAPABILITY, sizeof(IP_CAPABILITY), txCap); // Push txCap to paramBlock
gc_util_insert_parm_ref_ex(¶mBlock,
GCSET_CHAN_CAPABILITY, IPPARM_LOCAL_CAPABILITY, sizeof(IP_CAPABILITY), rxCap); // Push rxCap to paramBlock
/* Other code */
GC_PARM_BLKP retParamBlock = NULL;
gc_Extension(GCTGT_GCLIB_CHAN, 1, IPEXTID_SENDMSG, paramBlock, &retParamBlock, EV_ASYNC); // <- Here is where error is being raised
Approach 2 - Just write the same response as in the default handler by setting MIME_PART parameters.
// #.#.#.# - valid local IP
const char* optBody = "v=0\n\
o=Dialogic_SIP_CCLIB 0 1 IN IP4 #.#.#.#\n\
s=Dialogic_SIP_CCLIB\n\
i=session information\n\
c=IN IP4 #.#.#.#\n\
t=0 0\n\
m=audio 49152 RTP/AVP 8\n\
a=ptime:20";
const char* typeString = "Content-Type: application/sdp";
gc_util_insert_parm_ref_ex(&mimeBlock, IPSET_MIME, IPPARM_MIME_PART_TYPE, (unsigned long)strlen(typeString) + 1, (char *)typeString);
gc_util_insert_parm_val(&mimeBlock, IPSET_MIME, IPPARM_MIME_PART_BODY_SIZE, sizeof(unsigned long), strlen(optBody));
gc_util_insert_parm_val(&mimeBlock, IPSET_MIME, IPPARM_MIME_PART_BODY, sizeof(unsigned long), (unsigned long)optBody);
gc_util_insert_parm_val(¶mBlock, IPSET_MIME, IPPARM_MIME_PART, sizeof(unsigned long), (unsigned long)mimeBlock);
/* Other code */
GC_PARM_BLKP retParamBlock = NULL;
gc_Extension(GCTGT_GCLIB_CHAN, 1, IPEXTID_SENDMSG, paramBlock, &retParamBlock, EV_ASYNC); // <- Here is where error is being raised
Hello Jeff,
So what do you think about our implementation of the custom OPTIONS handler? Is there any error in the code?
Best Regards.
Generally speaking in order to modify the outgoing SDP content for SIP messages the application must be build and running in 3PCC mode. See chapter 5 here:
www.dialogic.com/.../globalcall_for_ip_hmp_v12.pdf
Are you running in 3pcc mode. If not, and its 1pcc then you will not be able to have access to making such changes as its controlled by the SIP stack only.
Jeff
Yes, if you need more information on handling of SUBSCRIBE refer to section 4.17 here:
www.dialogic.com/.../globalcall_for_ip_hmp_v12.pdf
This will help clean-up the underlying call failures since there is no more call legs to handle incoming calls, and other API based failures seen as a result.
Jeff
Similar to prior reply make sure recommendation in Sections 2.5 - 2.8 of the hmp4.1 software installation guide are set correctly on this system.
www.dialogic.com/.../release_install.pdf
Jeff
Hi Jeff,
We think we've finally got what you're meaning. In the Media Announcement attribute "m=audio 49152 RTP/AVP 0 8", the last figures list simply means codes specifying codecs, i.e. 0-g711 pcmu, 8-g711 pcma.
We'll see if it works. Unfortunately, GSM vendors' implementations sometimes don't work even if everything is conforming the RFC.
P.S. The link that you've shared pointing to RFC seems broken because it navigates to the completely non-IT related web-page.
Yes, that is correct. Btw, not sure what happened to the link but it was chapter 6 of rfc4566 for SDP.
Jeff
HI,
This was just an arbitrary value which was populated to maintain consistency of the property sheet across the DNI and HMP devices. Its not actually used in this case.
Jeff
Ok,
Where is "SerialNumber" stored?
How can I change it?
Thanks.
I use fx_open() to open fax device on D/600 JCT2E1 PCIe with channelname 'dxxxB1C1'
but it fails. how can I open fax Device on D/600 and how to get fax channelname if it differs with voice channelname.
Why do you ask, is there some issue here?
You cant change that as it generated at the driver level.
Jeff
Here is some information which may help:
Also, note you need to make sure the board is downloading fax based fwl.
Jeff
I am using fx_open() to open fax device on D/600 with channelname = dxxxB1C1
But it failes. what is channel name for fax device and how can I get fax channelnames.
Thanks Jeff, I read the post but I have another problem.
I set Interface to CTR4 and FirmwareFile to spfax.fwl but the DCM does not start. when I change FirmwareFile to Default it starts.
I found this post https://www.dialogic.com/den/developer_forums/f/7/p/1174/4170.aspx#4170
If this is correct then I can't have 60 Voice Channels and use fax feature with this board only.
please let me know if this is correct.
Yes,
The dialogic serial number was hard coded into some old software, and now the software won't work on a new server because it has a different dialogic serial number.
Can you sell me a "patch" that will set my serial number to what it was on my old server?
Much appreciated.
I do know that there was a restriction where CSP fwl could not be downloaded on the same span as ISDN on the dual span JCT boards. I guess the same could apply to fax fwl as well. I guess this is the reason why they started making the single span D/600jct board back then, to give the extra voice resources for those purposes.
Jeff
What O/S version and HMP SU are you seeing this on?
I believe there should still be a number there, as I checked on latest build from two systems and it was ok.
Jeff
