" /> SIP DN Annex options mess up hold - Genesys CTI User Forum

Author Topic: SIP DN Annex options mess up hold  (Read 4929 times)

Offline victor

  • Administrator
  • Hero Member
  • *****
  • Posts: 1419
  • Karma: 18
SIP DN Annex options mess up hold
« on: April 03, 2007, 09:47:20 AM »
Advertisement
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
« Last Edit: April 03, 2007, 10:17:26 AM by victor »

Offline victor

  • Administrator
  • Hero Member
  • *****
  • Posts: 1419
  • Karma: 18
Re: SIP DN Annex options mess up hold
« Reply #1 on: April 03, 2007, 10:34:27 AM »
To follow up on the post, you can see the five delay in SM between INVITE and ACK. Interesting, but still have no clue what the cause is!

[color=green][size=8pt]INVITE sip:conf=00900152a9276005@172.30.0.222:5061 SIP/2.0
From: "6005"<sip:6005@172.30.0.222:5060>;tag=06a04538070b4b1eb5092266ea8ee383
To: <sip:conf=00900152a9276005@172.30.0.222:5060>
Call-ID: 03C5C516-6D3A-40EE-B3D7-049FA59E2A0A-86@172.30.0.222
CSeq: 1 INVITE
Content-Length: 0
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK2477392B-73DD-4A8A-BF89-0175A0F68A3A-124
Contact: <sip:172.30.0.222:5060>
Max-Forwards: 70
Session-Expires: 1800;refresher=uac
Min-SE: 90
Supported: timer


gsip:DLG[44]: INVITE TD = TRN[89]
SM_PhoneDialog[44] event 12 INVITE

19:20:42.7650 ---- GKconnSIP[44x]::IncomingDLG(conf=00900152a9276005) accepted 200
  RTPLeg[444] created RTP:8088(fd=280), RTCP:8089(fd=304)

gsip:CL2CONN[264,UDP]:19:20:42.765 >>>> 722 bytes to 172.30.0.222:5060 >>>>
SIP/2.0 200 OK
From: "6005"<sip:6005@172.30.0.222:5060>;tag=06a04538070b4b1eb5092266ea8ee383
To: <sip:conf=00900152a9276005@172.30.0.222:5060>;tag=6B3B3ACA-7CA5-4187-A4DB-35B4D4024B97-44
Call-ID: 03C5C516-6D3A-40EE-B3D7-049FA59E2A0A-86@172.30.0.222
CSeq: 1 INVITE
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK2477392B-73DD-4A8A-BF89-0175A0F68A3A-124;received=172.30.0.222
Contact: <sip:172.30.0.222:5061>
Content-Type: application/sdp
Content-Length: 252

v=0
o=Genesys 86 86 IN IP4 172.30.0.222
s=StreamManager 7.2.002.02
c=IN IP4 172.30.0.222
t=0 0
m=audio 8088 RTP/AVP 0 8 18 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:18 g729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SM_PhoneDialog[44] event 14 CALLED/ResOK

gsip:CL2LIST[236,UDP]:19:20:42.765 <<<< 501 bytes from 172.30.0.222:5060 <<<<
INVITE sip:conf=00900152a9276005@172.30.0.222:5061 SIP/2.0
From: <sip:5000@172.30.0.222:5060>;tag=E43B8F2A-FB46-4A53-9909-E6DDD9EB5C89-86
To: <sip:conf=00900152a9276005@172.30.0.222:5060>
Call-ID: 03C5C516-6D3A-40EE-B3D7-049FA59E2A0A-87@172.30.0.222
CSeq: 1 INVITE
Content-Length: 0
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK2477392B-73DD-4A8A-BF89-0175A0F68A3A-125
Contact: <sip:172.30.0.222:5060>
Max-Forwards: 70
Session-Expires: 1800;refresher=uac
Min-SE: 90
Supported: timer


gsip:DLG[45]: INVITE TD = TRN[90]
SM_PhoneDialog[45] event 12 INVITE

19:20:42.7650 ---- GKconnSIP[45x]::IncomingDLG(conf=00900152a9276005) accepted 200
  RTPLeg[454] created RTP:8090(fd=312), RTCP:8091(fd=324)

gsip:CL2CONN[264,UDP]:19:20:42.765 >>>> 723 bytes to 172.30.0.222:5060 >>>>
SIP/2.0 200 OK
From: <sip:5000@172.30.0.222:5060>;tag=E43B8F2A-FB46-4A53-9909-E6DDD9EB5C89-86
To: <sip:conf=00900152a9276005@172.30.0.222:5060>;tag=6B3B3ACA-7CA5-4187-A4DB-35B4D4024B97-45
Call-ID: 03C5C516-6D3A-40EE-B3D7-049FA59E2A0A-87@172.30.0.222
CSeq: 1 INVITE
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK2477392B-73DD-4A8A-BF89-0175A0F68A3A-125;received=172.30.0.222
Contact: <sip:172.30.0.222:5061>
Content-Type: application/sdp
Content-Length: 252

v=0
o=Genesys 87 87 IN IP4 172.30.0.222
s=StreamManager 7.2.002.02
c=IN IP4 172.30.0.222
t=0 0
m=audio 8090 RTP/AVP 0 8 18 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:18 g729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SM_PhoneDialog[45] event 14 CALLED/ResOK

gsip:CL2LIST[236,UDP]:19:20:42.781 <<<< 658 bytes from 172.30.0.222:5060 <<<<
ACK sip:172.30.0.222:5061 SIP/2.0
From: "6005"<sip:6005@172.30.0.222:5060>;tag=06a04538070b4b1eb5092266ea8ee383
To: <sip:conf=00900152a9276005@172.30.0.222:5060>;tag=6B3B3ACA-7CA5-4187-A4DB-35B4D4024B97-44
Call-ID: 03C5C516-6D3A-40EE-B3D7-049FA59E2A0A-86@172.30.0.222
CSeq: 1 ACK
Content-Length: 228
Content-Type: application/sdp
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK2477392B-73DD-4A8A-BF89-0175A0F68A3A-124

v=0
o=- 0 0 IN IP4 172.30.0.170
s=CounterPath X-Lite 3.0
c=IN IP4 172.30.0.170
b=CT:1000
t=0 0
m=audio 22304 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 pcma/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

SM_PhoneDialog[44] event 26 CONNECTED/ACK
  m=audio RTPport=22304
    pt=0 codec=3(G.711/mu-law)
    pt=8 codec=4(G.711/A-law)
    pt=101 telephone-event
AnswerSDP(98:fffff)
  audio:0 codec=3(G.711/mu-law)
  audio:8 not used
RTPleg::setup [SM-7.2.002.02]-(rtp:8088)--(172.30.0.170:22304)
  (leg=444) state=67f[.rs.:ci:trs] codec=3(G.711/mu-law)
  timeWheel slot: 9 (+10/6)
SIPconf(id=00900152a9276005) conferenced (rec=no)
  RTPleg[444]:8088-ssrc[5f58] 3(G.711/mu-law) in=0/0 (0.00:0.00 sec)
got 1st RTP(leg=434,port=8086) at 19:20:42.7960
  -(0)- pt=0(PCMU) seq=1860 time=2043000 ssrc[fb5900ea] payload:len=160
  dropped
got 1st RTP(leg=444,port=8088) at 19:20:42.7960
  -(0)- pt=0(PCMU) seq=34060 time=3459448624 ssrc[cf9cb76] payload:len=160
  pushed to MCU(Q=0)
sent 1st RTP(leg=444,remote=22304) at 19:20:42.8430
  -(0)M pt=0(PCMU) seq=32513 time=3359 ssrc[5f58] payload:len=160

gsip:CL2LIST[236,UDP]:19:20:42.890 <<<< 598 bytes from 172.30.0.222:5060 <<<<
ACK sip:172.30.0.222:5061 SIP/2.0
From: "ALEGRIA-6004"<sip:6004@172.30.0.222:5060>;tag=230d2f3d
To: <sip:conf=00900152a9276005@172.30.0.222:5060>;tag=6B3B3ACA-7CA5-4187-A4DB-35B4D4024B97-43
Call-ID: 03C5C516-6D3A-40EE-B3D7-049FA59E2A0A-85@172.30.0.222
CSeq: 1 ACK
Content-Length: 184
Content-Type: application/sdp
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK2477392B-73DD-4A8A-BF89-0175A0F68A3A-123

v=0
o=- 4 3 IN IP4 172.30.0.128
s=CounterPath X-Lite 3.0
c=IN IP4 172.30.0.128
t=0 0
m=audio 1202 RTP/AVP 0 8 101
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SM_PhoneDialog[43] event 26 CONNECTED/ACK
  m=audio RTPport=1202 a=sendrecv
    pt=0 codec=3(G.711/mu-law)
    pt=8 codec=4(G.711/A-law)
    pt=101 telephone-event
AnswerSDP(98:fffff)
  audio:0 codec=3(G.711/mu-law)
  audio:8 not used


[size=10pt][b][color=red]gsip:CL2LIST[236,UDP]:19:20:45.484 <<<< 673 bytes from 172.30.0.222:5060 <<<<[/color][/b][/size]
ACK sip:172.30.0.222:5061 SIP/2.0
From: <sip:5000@172.30.0.222:5060>;tag=E43B8F2A-FB46-4A53-9909-E6DDD9EB5C89-86
To: <sip:conf=00900152a9276005@172.30.0.222:5060>;tag=6B3B3ACA-7CA5-4187-A4DB-35B4D4024B97-45
Call-ID: 03C5C516-6D3A-40EE-B3D7-049FA59E2A0A-87@172.30.0.222
CSeq: 1 ACK
Content-Length: 242
Content-Type: application/sdp
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK2477392B-73DD-4A8A-BF89-0175A0F68A3A-125

v=0
o=- 0 0 IN IP4 172.30.0.128
s=StreamManager 7.2.002.02
c=IN IP4 172.30.0.128
b=CT:1000
t=0 0
m=audio 44204 RTP/AVP 0 8 101
a=recvonly
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

[/size][/color]

What is really amazing is that this 3 second delay is only for ONE of the phones involved in the conversation - 500 (the same one that is monitoring)

(one of the parties in the conversation)
gsip:CL2LIST[236,UDP]:19:20:42.781 <<<< 658 bytes from 172.30.0.222:5060 <<<<
ACK sip:172.30.0.222:5061 SIP/2.0
From: "6005"<sip:6005@172.30.0.222:5060>;tag=06a04538070b4b1eb5092266ea8ee383

(another party in the conversation)
gsip:CL2LIST[236,UDP]:19:20:42.890 <<<< 598 bytes from 172.30.0.222:5060 <<<<
ACK sip:172.30.0.222:5061 SIP/2.0
From: "ALEGRIA-6004"<sip:6004@172.30.0.222:5060>;tag=230d2f3d

(and finally the monitoring party)
gsip:CL2LIST[236,UDP]:19:20:45.484 <<<< 673 bytes from 172.30.0.222:5060 <<<<
ACK sip:172.30.0.222:5061 SIP/2.0
From: <sip:5000@172.30.0.222:5060>;tag=E43B8F2A-FB46-4A53-9909-E6DDD9EB5C89-86

Only after monitoring party connects can the two original parties hear each other.
Any clue?

Offline bublepaw

  • Sr. Member
  • ****
  • Posts: 283
  • Karma: 10
Re: SIP DN Annex options mess up hold
« Reply #2 on: June 20, 2007, 04:28:51 PM »
Hi Victor

I'am working on implementing SIP client using Genesys SIP Building Block with SIP Server 7.5. Because I encountered similiar problems - different settings on DN Annex tab produces different results with transfers, hold etc, I posted SR on Genesys site to provide list of parameters that should be set on DN Annex tab for SIP Buliding block to work properly - as soon as I will get some satisfiying answer I will post it.

If however Genesys won't give me satisfying answer I will try to find some other SIP/RTP library for .NET to finish my project.

Regards

Paul

Offline S

  • Full Member
  • ***
  • Posts: 135
  • Karma: 1
Re: SIP DN Annex options mess up hold
« Reply #3 on: June 20, 2007, 07:08:23 PM »
the 5000 server has an option called test_reinvite-xxxxx.
should it start with test_ ? 6500 server's option does not start with test_.
Did u try removing it and testing again?