Hi, guys,
I have been perplexed for quite some time with how Genesys SIP Server manages to handle hold requests using SM.
[table][tr][td]
[attachimg=1]
[/td]
[td]
[attachimg=2]
[/td][/tr][/table]
As you can see, one is for 6005 and the other one is for 5000.
The only difference is the use of reinvite-requires-hold, which Genesys suggests setting to "true". 6005 hold works, but 5000 does not. (6005 hold puts 5000 on hold and pressing hold on 5000, puts 6005 on hold. )
So, I am a bit confused.
Interestingly enough, reinvite-requires-hold = true causes SIP CTI phone to stop sending calls to hold.
[table][tr][td]
[color=green][size=8pt]INVITE sip:annc@172.30.0.222:5061;play=music/on_hold SIP/2.0
From: <sip:6005@172.30.0.222>;tag=470d0af246c14a9aa82384bb96de9202
To: <sip:MOH_600@172.30.0.222:5060>
Call-ID: 6E1710EE-FBE1-4F72-9646-11FE1A57264C-36@172.30.0.222
CSeq: 1 INVITE
Content-Length: 0
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK03C0E31E-D6A9-4CAC-9D04-54EB26761ACE-142
Contact: <sip:172.30.0.222:5060>
Alert-Info: Ring Answer
Max-Forwards: 70
Session-Expires: 1800;refresher=uac
Min-SE: 90
Supported: timer
gsip:DLG[34]: INVITE TD = TRN[70]
SM_PhoneDialog[34] event 12 INVITE
18:28:48.5930 ---- GKconnSIP[34x]::IncomingDLG(annc) accepted 200
RTPLeg[344] created RTP:8068(fd=288), RTCP:8069(fd=292)
Probing music/on_hold (codecs:0x14b8)
music/on_hold_mulaw.wav Ok
music/on_hold_alaw.wav Ok
music/on_hold_g7231.wav Ok
music/on_hold_g729a.wav Ok
music/on_hold_gsm.wav Ok
music/on_hold_msgsm.wav Ok
gsip:CL2CONN[264,UDP]:18:28:48.593 >>>> 744 bytes to 172.30.0.222:5060 >>>>
SIP/2.0 200 OK
From: <sip:6005@172.30.0.222>;tag=470d0af246c14a9aa82384bb96de9202
To: <sip:MOH_600@172.30.0.222:5060>;tag=6B3B3ACA-7CA5-4187-A4DB-35B4D4024B97-34
Call-ID: 6E1710EE-FBE1-4F72-9646-11FE1A57264C-36@172.30.0.222
CSeq: 1 INVITE
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK03C0E31E-D6A9-4CAC-9D04-54EB26761ACE-142;received=172.30.0.222
Contact: <sip:172.30.0.222:5061>
Content-Type: application/sdp
Content-Length: 299
v=0
o=Genesys 67 67 IN IP4 172.30.0.222
s=StreamManager 7.2.002.02
c=IN IP4 172.30.0.222
t=0 0
m=audio 8068 RTP/AVP 0 8 4 18 3 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:4 g723/8000
a=rtpmap:18 g729/8000
a=rtpmap:3 gsm/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
SM_PhoneDialog[34] event 14 CALLED/ResOK
gsip:CL2LIST[236,UDP]:18:28:48.796 <<<< 501 bytes from 172.30.0.222:5060 <<<<
ACK sip:172.30.0.222:5061 SIP/2.0
From: <sip:6005@172.30.0.222>;tag=470d0af246c14a9aa82384bb96de9202
To: <sip:MOH_600@172.30.0.222:5060>;tag=6B3B3ACA-7CA5-4187-A4DB-35B4D4024B97-34
Call-ID: 6E1710EE-FBE1-4F72-9646-11FE1A57264C-36@172.30.0.222
CSeq: 1 ACK
Content-Length: 97
Content-Type: application/sdp
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK03C0E31E-D6A9-4CAC-9D04-54EB26761ACE-142
v=0
o=- 0 0 IN IP4 0.0.0.0
s=session
c=IN IP4 0.0.0.0
b=CT:1000
t=0 0
m=audio 0 RTP/AVP 0
SM_PhoneDialog[34] event 26 CONNECTED/ACK
m=audio RTPport=0
pt=0 codec=3(G.711/mu-law)
AnswerSDP(14b8:14b8)
audio:0 codec=3(G.711/mu-law)
RTPleg[344]:8068/8069 completed (remote 0.0.0.0:0)
RX=0/0+0(err=0) rtcp=0(err=0) ssrc[0] jitter=0(max=0)
TX=0/0+0(err=0) rtcp=0(err=0)
[/size][/color][/td]
[td]
[color=green][size=8pt]INVITE sip:annc@172.30.0.222:5061;play=music/on_hold SIP/2.0
From: "Ali" <sip:5000@172.30.0.222:5060>;tag=99842be62b144d02ad1d497e4b99cf08;epid=02aa62cb65
To: <sip:MOH_600@172.30.0.222:5060>
Call-ID: 6E1710EE-FBE1-4F72-9646-11FE1A57264C-35@172.30.0.222
CSeq: 1 INVITE
Content-Length: 0
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK03C0E31E-D6A9-4CAC-9D04-54EB26761ACE-138
Contact: <sip:172.30.0.222:5060>
Alert-Info: Ring Answer
Max-Forwards: 70
Session-Expires: 1800;refresher=uac
Min-SE: 90
Supported: timer
gsip:DLG[33]: INVITE TD = TRN[68]
SM_PhoneDialog[33] event 12 INVITE
18:28:00.5000 ---- GKconnSIP[33x]::IncomingDLG(annc) accepted 200
RTPLeg[334] created RTP:8066(fd=284), RTCP:8067(fd=288)
Probing music/on_hold (codecs:0x14b8)
music/on_hold_mulaw.wav Ok
music/on_hold_alaw.wav Ok
music/on_hold_g7231.wav Ok
music/on_hold_g729a.wav Ok
music/on_hold_gsm.wav Ok
music/on_hold_msgsm.wav Ok
gsip:CL2CONN[264,UDP]:18:28:00.500 >>>> 771 bytes to 172.30.0.222:5060 >>>>
SIP/2.0 200 OK
From: "Ali" <sip:5000@172.30.0.222:5060>;tag=99842be62b144d02ad1d497e4b99cf08;epid=02aa62cb65
To: <sip:MOH_600@172.30.0.222:5060>;tag=6B3B3ACA-7CA5-4187-A4DB-35B4D4024B97-33
Call-ID: 6E1710EE-FBE1-4F72-9646-11FE1A57264C-35@172.30.0.222
CSeq: 1 INVITE
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK03C0E31E-D6A9-4CAC-9D04-54EB26761ACE-138;received=172.30.0.222
Contact: <sip:172.30.0.222:5061>
Content-Type: application/sdp
Content-Length: 299
v=0
o=Genesys 65 65 IN IP4 172.30.0.222
s=StreamManager 7.2.002.02
c=IN IP4 172.30.0.222
t=0 0
m=audio 8066 RTP/AVP 0 8 4 18 3 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:4 g723/8000
a=rtpmap:18 g729/8000
a=rtpmap:3 gsm/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
SM_PhoneDialog[33] event 14 CALLED/ResOK
got 1st RTP(leg=334,port=8066) at 18:28:00.5310
-(0)- pt=0(PCMU) seq=38314 time=347508616 ssrc[8755662e] payload:len=160
dropped
gsip:CL2LIST[236,UDP]:18:28:00.531 <<<< 692 bytes from 172.30.0.222:5060 <<<<
ACK sip:172.30.0.222:5061 SIP/2.0
From: "Ali" <sip:5000@172.30.0.222:5060>;tag=99842be62b144d02ad1d497e4b99cf08;epid=02aa62cb65
To: <sip:MOH_600@172.30.0.222:5060>;tag=6B3B3ACA-7CA5-4187-A4DB-35B4D4024B97-33
Call-ID: 6E1710EE-FBE1-4F72-9646-11FE1A57264C-35@172.30.0.222
CSeq: 1 ACK
Content-Length: 260
Content-Type: application/sdp
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK03C0E31E-D6A9-4CAC-9D04-54EB26761ACE-138
v=0
o=- 0 0 IN IP4 172.30.0.128
s=session
c=IN IP4 172.30.0.128
b=CT:1000
t=0 0
m=audio 57266 RTP/AVP 0 8 4 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 pcma/8000
a=rtpmap:4 g723/8000
a=rtpmap:3 gsm/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
SM_PhoneDialog[33] event 26 CONNECTED/ACK
m=audio RTPport=57266
pt=0 codec=3(G.711/mu-law)
pt=8 codec=4(G.711/A-law)
pt=4 codec=5(G.723.1)
pt=3 codec=10(GSM)
pt=101 telephone-event
AnswerSDP(14b8:14b8)
audio:0 codec=3(G.711/mu-law)
audio:8 not used
audio:4 not used
audio:3 not used
RTPleg::setup [SM-7.2.002.02]-(rtp:8066)--(172.30.0.128:57266)
(leg=334) state=67f[.rs.:ci:trs] codec=3(G.711/mu-law)
SIPconnAnnc::setup_media/audio
RTPfile[7d58] seq=21986 time=10613
WAVfile(music/on_hold_mulaw.wav) fmt=7(G.711/mu-law) chan=1 sample=8000/sec avg=8000 blk=1 bps=8
data_size=1344985 (~168.1 sec)[/size][/color][/td][/tr][/table]
So, I am a bit confused. Do the options apply on how this DN handles the hold or how it applies the hold?
In other words, when I press a HOLD button on 6005 and put 5000 on hold, is it being put on hold according to the settings in 5000 or 6005?
Judging from the log, it seems that settings in 6005 tell it how to place calls to other DNs on hold, and not itself. Which of course, does not make any sense...
I have noticed that reinvite-requires-hold needs to be set to "false" in order to get Genesys SM to work with me.
Yet, Genesys suggests setting it to "true". I am sooooooooooooo confused.
reinvite-requires-hold = true would mean that SDP in ACK would not be processed by TServer and would result in something like this:
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK2477392B-73DD-4A8A-BF89-0175A0F68A3A-5
v=0
o=- 0 0 IN IP4 0.0.0.0
s=session
c=IN IP4 0.0.0.0
b=CT:1000
t=0 0
m=audio 0 RTP/AVP 0
How can it possibly work unless they want you to re-write the whole SDP?
Why am I asking? Because, supposedly, there is a delay for conferenced calls for up to 10 seconds if the options in Annex of DN are not in the order suggested by Genesys.
And that is a big problem - can you imagine waiting 10 second for a conference call audio to be connected? Does anyone know a way to fix that?
(sorry for blabbering)
Best regards,
Vic