Incorrect SDP from sipX after xfer completion

[Jeff Pyle]

Hello,

At the end of another
thread<http://list.sipfoundry.org/archive/sipx-users/msg41614.html>Tony
suggested I try attended transfers and some other parking related
operations against an Adtran TA900-series gateway. It seemed there had
been some friction here in the past.

I was able to test attended and unattended transfers with sipX 4.6 on an
Adtran TA908E. The global config option "voice transfer-mode network" is
required to support REFERs. Without it the results will be undesirable.
With that line, however, unattended transfers worked just fine

Attended transfers yielded no audio when the transfer completed if the
Adtran is the C-leg of the transfer. Here's why:

This is the SDP of the INVITE with Replaces that arrives at the Adtran from
sipX to wrap up the transfer:

v=0

o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000

This is correct, telling the Adtran to send audio to 172.21.201.60 (c=
line) on port 2250 (m= line). 172.21.201.60 is the IP address of the
Polycom who was the A-leg of the call.

As part of some DSP cleanup ops the Adtran starts a reINVITE transaction
with late negotiation as soon as the above transaction is completed. The
offer SDP on sipX's 200 OK of that transaction looks like this:

v=0

o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54

Notice the c= and m= lines have changed. sipX is now telling the Adtran to
send audio to 192.168.54.46, the IP address of the sipX instance itself.
This is why the A-leg Polycom at 172.21.201.60 doesn't receive any audio
after the transfer - sipX told the Adtran to send the audio elsewhere.

Any idea why sipX might do that?

As a bandaid, one can prevent the Adtran from sending the reINVITE by
adding "no prefer reinvite-without-sdp" to the voice trunk configured to
talk to sipX. This command is available only in prerelease code at the
moment. I believe it will be GA by the end of the month.


- Jeff

[Joegen Baclor]

Jeff, good bug reporting!

By late negotiation, do you mean INVITE with no SDP? There is a known
issue with NAT traversal plugin not being able to handle this properly.
If you don't mind, please open a tracker in jira and attach packet captures.

Post by Jeff Pyle
Hello,
At the end of another thread
<http://list.sipfoundry.org/archive/sipx-users/msg41614.html> Tony
suggested I try attended transfers and some other parking related
operations against an Adtran TA900-series gateway. It seemed there
had been some friction here in the past.
I was able to test attended and unattended transfers with sipX 4.6 on
an Adtran TA908E. The global config option "voice transfer-mode
network" is required to support REFERs. Without it the results will
be undesirable. With that line, however, unattended transfers worked
just fine
Attended transfers yielded no audio when the transfer completed if the
This is the SDP of the INVITE with Replaces that arrives at the Adtran
v=0
o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
This is correct, telling the Adtran to send audio to 172.21.201.60 (c=
line) on port 2250 (m= line). 172.21.201.60 is the IP address of the
Polycom who was the A-leg of the call.
As part of some DSP cleanup ops the Adtran starts a reINVITE
transaction with late negotiation as soon as the above transaction is
completed. The offer SDP on sipX's 200 OK of that transaction looks
v=0
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54
Notice the c= and m= lines have changed. sipX is now telling the
Adtran to send audio to 192.168.54.46, the IP address of the sipX
instance itself. This is why the A-leg Polycom at 172.21.201.60
doesn't receive any audio after the transfer - sipX told the Adtran to
send the audio elsewhere.
Any idea why sipX might do that?
As a bandaid, one can prevent the Adtran from sending the reINVITE by
adding "no prefer reinvite-without-sdp" to the voice trunk configured
to talk to sipX. This command is available only in prerelease code at
the moment. I believe it will be GA by the end of the month.
- Jeff
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Jeff Pyle]

Joegen,

Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.

In my configuration there is no NAT whatsoever. Is there a way to disable
NAT traversal completely, thereby working around this issue for the time
being?


- Jeff

Post by Joegen Baclor
Jeff, good bug reporting!
By late negotiation, do you mean INVITE with no SDP? There is a known
issue with NAT traversal plugin not being able to handle this properly. If
you don't mind, please open a tracker in jira and attach packet captures.
Hello,
At the end of another thread<http://list.sipfoundry.org/archive/sipx-users/msg41614.html>Tony suggested I try attended transfers and some other parking related
operations against an Adtran TA900-series gateway. It seemed there had
been some friction here in the past.
I was able to test attended and unattended transfers with sipX 4.6 on an
Adtran TA908E. The global config option "voice transfer-mode network" is
required to support REFERs. Without it the results will be undesirable.
With that line, however, unattended transfers worked just fine
Attended transfers yielded no audio when the transfer completed if the
This is the SDP of the INVITE with Replaces that arrives at the Adtran
v=0

o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000

This is correct, telling the Adtran to send audio to 172.21.201.60 (c=
line) on port 2250 (m= line). 172.21.201.60 is the IP address of the
Polycom who was the A-leg of the call.
As part of some DSP cleanup ops the Adtran starts a reINVITE transaction
with late negotiation as soon as the above transaction is completed. The
v=0

o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54

Notice the c= and m= lines have changed. sipX is now telling the Adtran
to send audio to 192.168.54.46, the IP address of the sipX instance itself.
This is why the A-leg Polycom at 172.21.201.60 doesn't receive any audio
after the transfer - sipX told the Adtran to send the audio elsewhere.
Any idea why sipX might do that?
As a bandaid, one can prevent the Adtran from sending the reINVITE by
adding "no prefer reinvite-without-sdp" to the voice trunk configured to
talk to sipX. This command is available only in prerelease code at the
moment. I believe it will be GA by the end of the month.
- Jeff
_______________________________________________
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Tony Graziano]

Is the adtran setup as an unmanaged gateway and on the same network as
sipx? If so that would be the correct configuration.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Joegen,
Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.
In my configuration there is no NAT whatsoever. Is there a way to disable
NAT traversal completely, thereby working around this issue for the time
being?
- Jeff

Post by Joegen Baclor
Jeff, good bug reporting!
By late negotiation, do you mean INVITE with no SDP? There is a known
issue with NAT traversal plugin not being able to handle this properly. If
you don't mind, please open a tracker in jira and attach packet captures.
Hello,
At the end of another thread<http://list.sipfoundry.org/archive/sipx-users/msg41614.html>Tony suggested I try attended transfers and some other parking related
operations against an Adtran TA900-series gateway. It seemed there had
been some friction here in the past.
I was able to test attended and unattended transfers with sipX 4.6 on
an Adtran TA908E. The global config option "voice transfer-mode network"
is required to support REFERs. Without it the results will be undesirable.
With that line, however, unattended transfers worked just fine
Attended transfers yielded no audio when the transfer completed if the
This is the SDP of the INVITE with Replaces that arrives at the Adtran
v=0

o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000

This is correct, telling the Adtran to send audio to 172.21.201.60 (c=
line) on port 2250 (m= line). 172.21.201.60 is the IP address of the
Polycom who was the A-leg of the call.
As part of some DSP cleanup ops the Adtran starts a reINVITE
transaction with late negotiation as soon as the above transaction is
completed. The offer SDP on sipX's 200 OK of that transaction looks like
v=0

o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54

Notice the c= and m= lines have changed. sipX is now telling the
Adtran to send audio to 192.168.54.46, the IP address of the sipX instance
itself. This is why the A-leg Polycom at 172.21.201.60 doesn't receive any
audio after the transfer - sipX told the Adtran to send the audio elsewhere.
Any idea why sipX might do that?
As a bandaid, one can prevent the Adtran from sending the reINVITE by
adding "no prefer reinvite-without-sdp" to the voice trunk configured to
talk to sipX. This command is available only in prerelease code at the
moment. I believe it will be GA by the end of the month.
- Jeff
_______________________________________________
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Jeff Pyle]

Tony,

Yes, and yes.


- Jeff


On Tue, Sep 25, 2012 at 12:26 PM, Tony Graziano <

Post by Tony Graziano
Is the adtran setup as an unmanaged gateway and on the same network as
sipx? If so that would be the correct configuration.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Joegen,
Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.
In my configuration there is no NAT whatsoever. Is there a way to
disable NAT traversal completely, thereby working around this issue for the
time being?
- Jeff

Post by Joegen Baclor
Jeff, good bug reporting!
By late negotiation, do you mean INVITE with no SDP? There is a known
issue with NAT traversal plugin not being able to handle this properly. If
you don't mind, please open a tracker in jira and attach packet captures.
Hello,
At the end of another thread<http://list.sipfoundry.org/archive/sipx-users/msg41614.html>Tony suggested I try attended transfers and some other parking related
operations against an Adtran TA900-series gateway. It seemed there had
been some friction here in the past.
I was able to test attended and unattended transfers with sipX 4.6 on
an Adtran TA908E. The global config option "voice transfer-mode network"
is required to support REFERs. Without it the results will be undesirable.
With that line, however, unattended transfers worked just fine
Attended transfers yielded no audio when the transfer completed if the
This is the SDP of the INVITE with Replaces that arrives at the Adtran
v=0

o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000

This is correct, telling the Adtran to send audio to 172.21.201.60 (c=
line) on port 2250 (m= line). 172.21.201.60 is the IP address of the
Polycom who was the A-leg of the call.
As part of some DSP cleanup ops the Adtran starts a reINVITE
transaction with late negotiation as soon as the above transaction is
completed. The offer SDP on sipX's 200 OK of that transaction looks like
v=0

o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54

Notice the c= and m= lines have changed. sipX is now telling the
Adtran to send audio to 192.168.54.46, the IP address of the sipX instance
itself. This is why the A-leg Polycom at 172.21.201.60 doesn't receive any
audio after the transfer - sipX told the Adtran to send the audio elsewhere.
Any idea why sipX might do that?
As a bandaid, one can prevent the Adtran from sending the reINVITE by
adding "no prefer reinvite-without-sdp" to the voice trunk configured to
talk to sipX. This command is available only in prerelease code at the
moment. I believe it will be GA by the end of the month.
- Jeff
_______________________________________________
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Tony Graziano]

Then other than ensuring the intranet subnet is listed (i'm sure it
is), this is only happening on attended transfer? you can disable
server behind nat and enable nat traversal, i'm not certain it would
change things but I guess it would be worth a try to see if the call
can complete.

Post by Jeff Pyle
Tony,
Yes, and yes.
- Jeff
On Tue, Sep 25, 2012 at 12:26 PM, Tony Graziano

Post by Tony Graziano
Is the adtran setup as an unmanaged gateway and on the same network as
sipx? If so that would be the correct configuration.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Joegen,
Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.
In my configuration there is no NAT whatsoever. Is there a way to
disable NAT traversal completely, thereby working around this issue for the
time being?
- Jeff

Post by Joegen Baclor
Jeff, good bug reporting!
By late negotiation, do you mean INVITE with no SDP? There is a known
issue with NAT traversal plugin not being able to handle this properly. If
you don't mind, please open a tracker in jira and attach packet captures.
Hello,
At the end of another thread Tony suggested I try attended transfers and
some other parking related operations against an Adtran TA900-series
gateway. It seemed there had been some friction here in the past.
I was able to test attended and unattended transfers with sipX 4.6 on an
Adtran TA908E. The global config option "voice transfer-mode network" is
required to support REFERs. Without it the results will be undesirable.
With that line, however, unattended transfers worked just fine
Attended transfers yielded no audio when the transfer completed if the
This is the SDP of the INVITE with Replaces that arrives at the Adtran

v=0
o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000

This is correct, telling the Adtran to send audio to 172.21.201.60 (c=
line) on port 2250 (m= line). 172.21.201.60 is the IP address of the
Polycom who was the A-leg of the call.
As part of some DSP cleanup ops the Adtran starts a reINVITE transaction
with late negotiation as soon as the above transaction is completed. The

v=0
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54

Notice the c= and m= lines have changed. sipX is now telling the Adtran
to send audio to 192.168.54.46, the IP address of the sipX instance itself.
This is why the A-leg Polycom at 172.21.201.60 doesn't receive any audio
after the transfer - sipX told the Adtran to send the audio elsewhere.
Any idea why sipX might do that?
As a bandaid, one can prevent the Adtran from sending the reINVITE by
adding "no prefer reinvite-without-sdp" to the voice trunk configured to
talk to sipX. This command is available only in prerelease code at the
moment. I believe it will be GA by the end of the month.
- Jeff
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013!

[Jeff Pyle]

Tony,

I've tried all the combinations of these two options. It's the "Enable NAT
Traversal" one that breaks the attended transfer. At this time that's the
only call flow I've seen trouble with, but I haven't tried that many either.

I'll include this info on the jira.


- Jeff



On Tue, Sep 25, 2012 at 12:44 PM, Tony Graziano <

Post by Tony Graziano
Then other than ensuring the intranet subnet is listed (i'm sure it
is), this is only happening on attended transfer? you can disable
server behind nat and enable nat traversal, i'm not certain it would
change things but I guess it would be worth a try to see if the call
can complete.

Post by Jeff Pyle
Tony,
Yes, and yes.
- Jeff
On Tue, Sep 25, 2012 at 12:26 PM, Tony Graziano

Post by Tony Graziano
Is the adtran setup as an unmanaged gateway and on the same network as
sipx? If so that would be the correct configuration.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013!

Post by Jeff Pyle
Joegen,
Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.
In my configuration there is no NAT whatsoever. Is there a way to
disable NAT traversal completely, thereby working around this issue

for the

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle
time being?
- Jeff

Post by Joegen Baclor
Jeff, good bug reporting!
By late negotiation, do you mean INVITE with no SDP? There is a known
issue with NAT traversal plugin not being able to handle this

properly. If

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle

Post by Joegen Baclor
you don't mind, please open a tracker in jira and attach packet

captures.

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle

Post by Joegen Baclor
Hello,
At the end of another thread Tony suggested I try attended transfers

and

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle

Post by Joegen Baclor
some other parking related operations against an Adtran TA900-series
gateway. It seemed there had been some friction here in the past.
I was able to test attended and unattended transfers with sipX 4.6 on

an

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle

Post by Joegen Baclor
Adtran TA908E. The global config option "voice transfer-mode

network" is

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle

Post by Joegen Baclor
required to support REFERs. Without it the results will be

undesirable.

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle

Post by Joegen Baclor
With that line, however, unattended transfers worked just fine
Attended transfers yielded no audio when the transfer completed if the
This is the SDP of the INVITE with Replaces that arrives at the Adtran

v=0
o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000

This is correct, telling the Adtran to send audio to 172.21.201.60 (c=
line) on port 2250 (m= line). 172.21.201.60 is the IP address of the
Polycom who was the A-leg of the call.
As part of some DSP cleanup ops the Adtran starts a reINVITE

transaction

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle

Post by Joegen Baclor
with late negotiation as soon as the above transaction is completed.

The

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle

Post by Joegen Baclor

v=0
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54

Notice the c= and m= lines have changed. sipX is now telling the

Adtran

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle

Post by Joegen Baclor
to send audio to 192.168.54.46, the IP address of the sipX instance

itself.

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle

Post by Joegen Baclor
This is why the A-leg Polycom at 172.21.201.60 doesn't receive any

audio

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle

Post by Joegen Baclor
after the transfer - sipX told the Adtran to send the audio elsewhere.
Any idea why sipX might do that?
As a bandaid, one can prevent the Adtran from sending the reINVITE by
adding "no prefer reinvite-without-sdp" to the voice trunk configured

to

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle

Post by Joegen Baclor
talk to sipX. This command is available only in prerelease code at

the

Post by Jeff Pyle

Post by Tony Graziano

Post by Jeff Pyle

Post by Joegen Baclor
moment. I believe it will be GA by the end of the month.
- Jeff
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013!
--
Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Tony Graziano]

Thanks. It would appear (to me) that enabling nat confuses the
transaction which thinks during an attended transfer that the gateway
or phone is actually behind a nat endpoint, when it is not. It makes
no difference that the UA and the gateway/sip server is on a different
subnet, as long as it is routed and not nat'ted, which you have stated
these are not behind nat, and I believe you.

Thanks for the JIRA.

Post by Jeff Pyle
Tony,
I've tried all the combinations of these two options. It's the "Enable NAT
Traversal" one that breaks the attended transfer. At this time that's the
only call flow I've seen trouble with, but I haven't tried that many either.
I'll include this info on the jira.
- Jeff
On Tue, Sep 25, 2012 at 12:44 PM, Tony Graziano

Post by Tony Graziano
Then other than ensuring the intranet subnet is listed (i'm sure it
is), this is only happening on attended transfer? you can disable
server behind nat and enable nat traversal, i'm not certain it would
change things but I guess it would be worth a try to see if the call
can complete.

Post by Jeff Pyle
Tony,
Yes, and yes.
- Jeff
On Tue, Sep 25, 2012 at 12:26 PM, Tony Graziano

Post by Tony Graziano
Is the adtran setup as an unmanaged gateway and on the same network as
sipx? If so that would be the correct configuration.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Joegen,
Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.
In my configuration there is no NAT whatsoever. Is there a way to
disable NAT traversal completely, thereby working around this issue for the
time being?
- Jeff

Post by Joegen Baclor
Jeff, good bug reporting!
By late negotiation, do you mean INVITE with no SDP? There is a known
issue with NAT traversal plugin not being able to handle this properly. If
you don't mind, please open a tracker in jira and attach packet captures.
Hello,
At the end of another thread Tony suggested I try attended transfers and
some other parking related operations against an Adtran TA900-series
gateway. It seemed there had been some friction here in the past.
I was able to test attended and unattended transfers with sipX 4.6 on an
Adtran TA908E. The global config option "voice transfer-mode network" is
required to support REFERs. Without it the results will be undesirable.
With that line, however, unattended transfers worked just fine
Attended transfers yielded no audio when the transfer completed if the
This is the SDP of the INVITE with Replaces that arrives at the Adtran

v=0
o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000

This is correct, telling the Adtran to send audio to 172.21.201.60 (c=
line) on port 2250 (m= line). 172.21.201.60 is the IP address of the
Polycom who was the A-leg of the call.
As part of some DSP cleanup ops the Adtran starts a reINVITE transaction
with late negotiation as soon as the above transaction is completed.
The

v=0
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54

Notice the c= and m= lines have changed. sipX is now telling the Adtran
to send audio to 192.168.54.46, the IP address of the sipX instance itself.
This is why the A-leg Polycom at 172.21.201.60 doesn't receive any audio
after the transfer - sipX told the Adtran to send the audio elsewhere.
Any idea why sipX might do that?
As a bandaid, one can prevent the Adtran from sending the reINVITE by
adding "no prefer reinvite-without-sdp" to the voice trunk configured to
talk to sipX. This command is available only in prerelease code at the
moment. I believe it will be GA by the end of the month.
- Jeff
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013!
--
Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013!

[Joegen Baclor]

Post by Jeff Pyle

Post by Jeff Pyle
In my configuration there is no NAT whatsoever. Is there a way to

disable NAT traversal completely, thereby working around this issue for
the time being?

I should also add sipX being behind a firewall.

Post by Jeff Pyle
Joegen,
Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.
In my configuration there is no NAT whatsoever. Is there a way to
disable NAT traversal completely, thereby working around this issue
for the time being?
- Jeff
Jeff, good bug reporting!
By late negotiation, do you mean INVITE with no SDP? There is a
known issue with NAT traversal plugin not being able to handle
this properly. If you don't mind, please open a tracker in jira
and attach packet captures.

Post by Jeff Pyle
Hello,
At the end of another thread
<http://list.sipfoundry.org/archive/sipx-users/msg41614.html>
Tony suggested I try attended transfers and some other parking
related operations against an Adtran TA900-series gateway. It
seemed there had been some friction here in the past.
I was able to test attended and unattended transfers with sipX
4.6 on an Adtran TA908E. The global config option "voice
transfer-mode network" is required to support REFERs. Without it
the results will be undesirable. With that line, however,
unattended transfers worked just fine
Attended transfers yielded no audio when the transfer completed
This is the SDP of the INVITE with Replaces that arrives at the
v=0
o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
This is correct, telling the Adtran to send audio to
172.21.201.60 (c= line) on port 2250 (m= line). 172.21.201.60 is
the IP address of the Polycom who was the A-leg of the call.
As part of some DSP cleanup ops the Adtran starts a reINVITE
transaction with late negotiation as soon as the above
transaction is completed. The offer SDP on sipX's 200 OK of that
v=0
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54
Notice the c= and m= lines have changed. sipX is now telling the
Adtran to send audio to 192.168.54.46, the IP address of the sipX
instance itself. This is why the A-leg Polycom at 172.21.201.60
doesn't receive any audio after the transfer - sipX told the
Adtran to send the audio elsewhere.
Any idea why sipX might do that?
As a bandaid, one can prevent the Adtran from sending the
reINVITE by adding "no prefer reinvite-without-sdp" to the voice
trunk configured to talk to sipX. This command is available only
in prerelease code at the moment. I believe it will be GA by the
end of the month.
- Jeff
_______________________________________________
sipx-users mailing list
List Archive:http://list.sipfoundry.org/archive/sipx-users/

[Jeff Pyle]

Joegen,

In my case all the SIP-speaking components are directly routable to each
other with no firewalls and therefore no NAT in between. I don't
understand what you mean by "sipX being behind a firewall". Is that
relevant to the NAT traversal issue you mentioned?


- Jeff

Post by Jeff Pyle

Post by Joegen Baclor

Post by Jeff Pyle
In my configuration there is no NAT whatsoever. Is there a way to

disable NAT traversal completely, thereby working around this issue for the
time being?
I should also add sipX being behind a firewall.
Joegen,
Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.
In my configuration there is no NAT whatsoever. Is there a way to
disable NAT traversal completely, thereby working around this issue for the
time being?
- Jeff

Post by Joegen Baclor
Jeff, good bug reporting!
By late negotiation, do you mean INVITE with no SDP? There is a known
issue with NAT traversal plugin not being able to handle this properly. If
you don't mind, please open a tracker in jira and attach packet captures.
Hello,
At the end of another thread<http://list.sipfoundry.org/archive/sipx-users/msg41614.html>Tony suggested I try attended transfers and some other parking related
operations against an Adtran TA900-series gateway. It seemed there had
been some friction here in the past.
I was able to test attended and unattended transfers with sipX 4.6 on
an Adtran TA908E. The global config option "voice transfer-mode network"
is required to support REFERs. Without it the results will be undesirable.
With that line, however, unattended transfers worked just fine
Attended transfers yielded no audio when the transfer completed if the
This is the SDP of the INVITE with Replaces that arrives at the Adtran
v=0

Post by Jeff Pyle
o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000

This is correct, telling the Adtran to send audio to 172.21.201.60 (c=
line) on port 2250 (m= line). 172.21.201.60 is the IP address of the
Polycom who was the A-leg of the call.
As part of some DSP cleanup ops the Adtran starts a reINVITE
transaction with late negotiation as soon as the above transaction is
completed. The offer SDP on sipX's 200 OK of that transaction looks like
v=0

Post by Jeff Pyle
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54

Notice the c= and m= lines have changed. sipX is now telling the
Adtran to send audio to 192.168.54.46, the IP address of the sipX instance
itself. This is why the A-leg Polycom at 172.21.201.60 doesn't receive any
audio after the transfer - sipX told the Adtran to send the audio elsewhere.
Any idea why sipX might do that?
As a bandaid, one can prevent the Adtran from sending the reINVITE by
adding "no prefer reinvite-without-sdp" to the voice trunk configured to
talk to sipX. This command is available only in prerelease code at the
moment. I believe it will be GA by the end of the month.
- Jeff
_______________________________________________
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Joegen Baclor]

Jeff,

I might be missing something but the SDP you pasted

o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54


172.21.201.60 being the original IP of the polycom

and

192.168.54.46 being the IP of sipX

I assumed that there is a firewall linking these two networks. Maybe a
packet capture and a topology description would save us the need to
speculate much :-)

Post by Jeff Pyle
Joegen,
In my case all the SIP-speaking components are directly routable to
each other with no firewalls and therefore no NAT in between. I don't
understand what you mean by "sipX being behind a firewall". Is that
relevant to the NAT traversal issue you mentioned?
- Jeff

Post by Jeff Pyle

Post by Jeff Pyle
In my configuration there is no NAT whatsoever. Is there a way

to disable NAT traversal completely, thereby working around this
issue for the time being?
I should also add sipX being behind a firewall.

Post by Jeff Pyle
Joegen,
Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.
In my configuration there is no NAT whatsoever. Is there a way
to disable NAT traversal completely, thereby working around this
issue for the time being?
- Jeff
On Tue, Sep 25, 2012 at 12:09 PM, Joegen Baclor
Jeff, good bug reporting!
By late negotiation, do you mean INVITE with no SDP? There
is a known issue with NAT traversal plugin not being able to
handle this properly. If you don't mind, please open a
tracker in jira and attach packet captures.

Post by Jeff Pyle
Hello,
At the end of another thread
<http://list.sipfoundry.org/archive/sipx-users/msg41614.html> Tony
suggested I try attended transfers and some other parking
related operations against an Adtran TA900-series gateway.
It seemed there had been some friction here in the past.
I was able to test attended and unattended transfers with
sipX 4.6 on an Adtran TA908E. The global config option
"voice transfer-mode network" is required to support REFERs.
Without it the results will be undesirable. With that
line, however, unattended transfers worked just fine
Attended transfers yielded no audio when the transfer
completed if the Adtran is the C-leg of the transfer.
This is the SDP of the INVITE with Replaces that arrives at
v=0
o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
This is correct, telling the Adtran to send audio to
172.21.201.60 (c= line) on port 2250 (m= line).
172.21.201.60 is the IP address of the Polycom who was the
A-leg of the call.
As part of some DSP cleanup ops the Adtran starts a reINVITE
transaction with late negotiation as soon as the above
transaction is completed. The offer SDP on sipX's 200 OK of
v=0
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54
Notice the c= and m= lines have changed. sipX is now
telling the Adtran to send audio to 192.168.54.46, the IP
address of the sipX instance itself. This is why the A-leg
Polycom at 172.21.201.60 doesn't receive any audio after the
transfer - sipX told the Adtran to send the audio elsewhere.
Any idea why sipX might do that?
As a bandaid, one can prevent the Adtran from sending the
reINVITE by adding "no prefer reinvite-without-sdp" to the
voice trunk configured to talk to sipX. This command is
available only in prerelease code at the moment. I believe
it will be GA by the end of the month.
- Jeff
_______________________________________________
sipx-users mailing list
List Archive:http://list.sipfoundry.org/archive/sipx-users/

[Tony Graziano]

By default sipx automatically assumes the following:

10.0.0.0/8
172.160.0./12
192.168.0.0/16

are on your network.

If these two nodes mentioned below are on your network, just be sure
the statements are correct in reflecting your actual networks and
their mask, otherwise I see no foul if the networks can route or
bridge to each other without nat.

Post by Joegen Baclor
Jeff,
I might be missing something but the SDP you pasted
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54
172.21.201.60 being the original IP of the polycom
and
192.168.54.46 being the IP of sipX
I assumed that there is a firewall linking these two networks. Maybe a
packet capture and a topology description would save us the need to
speculate much :-)
Joegen,
In my case all the SIP-speaking components are directly routable to each
other with no firewalls and therefore no NAT in between. I don't understand
what you mean by "sipX being behind a firewall". Is that relevant to the
NAT traversal issue you mentioned?
- Jeff

Post by Joegen Baclor

Post by Joegen Baclor

Post by Jeff Pyle
In my configuration there is no NAT whatsoever. Is there a way to
disable NAT traversal completely, thereby working around this issue for the
time being?

I should also add sipX being behind a firewall.
Joegen,
Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.
In my configuration there is no NAT whatsoever. Is there a way to disable
NAT traversal completely, thereby working around this issue for the time
being?
- Jeff

Post by Joegen Baclor
Jeff, good bug reporting!
By late negotiation, do you mean INVITE with no SDP? There is a known
issue with NAT traversal plugin not being able to handle this properly. If
you don't mind, please open a tracker in jira and attach packet captures.
Hello,
At the end of another thread Tony suggested I try attended transfers and
some other parking related operations against an Adtran TA900-series
gateway. It seemed there had been some friction here in the past.
I was able to test attended and unattended transfers with sipX 4.6 on an
Adtran TA908E. The global config option "voice transfer-mode network" is
required to support REFERs. Without it the results will be undesirable.
With that line, however, unattended transfers worked just fine
Attended transfers yielded no audio when the transfer completed if the
This is the SDP of the INVITE with Replaces that arrives at the Adtran

Post by Jeff Pyle
v=0
o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000

This is correct, telling the Adtran to send audio to 172.21.201.60 (c=
line) on port 2250 (m= line). 172.21.201.60 is the IP address of the
Polycom who was the A-leg of the call.
As part of some DSP cleanup ops the Adtran starts a reINVITE transaction
with late negotiation as soon as the above transaction is completed. The

Post by Jeff Pyle
v=0
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54

Notice the c= and m= lines have changed. sipX is now telling the Adtran
to send audio to 192.168.54.46, the IP address of the sipX instance itself.
This is why the A-leg Polycom at 172.21.201.60 doesn't receive any audio
after the transfer - sipX told the Adtran to send the audio elsewhere.
Any idea why sipX might do that?
As a bandaid, one can prevent the Adtran from sending the reINVITE by
adding "no prefer reinvite-without-sdp" to the voice trunk configured to
talk to sipX. This command is available only in prerelease code at the
moment. I believe it will be GA by the end of the month.
- Jeff
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013!

[Jeff Pyle]

Joegen,

I fully understand my network so I don't see where the problem is. :)

All the details, including an adequate topology description, are now in
XX-10464 <http://track.sipfoundry.org/browse/XX-10464>.



- Jeff

Post by Joegen Baclor
Jeff,
I might be missing something but the SDP you pasted
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54
172.21.201.60 being the original IP of the polycom
and
192.168.54.46 being the IP of sipX
I assumed that there is a firewall linking these two networks. Maybe a
packet capture and a topology description would save us the need to
speculate much :-)
Joegen,
In my case all the SIP-speaking components are directly routable to each
other with no firewalls and therefore no NAT in between. I don't
understand what you mean by "sipX being behind a firewall". Is that
relevant to the NAT traversal issue you mentioned?
- Jeff

Post by Jeff Pyle

Post by Joegen Baclor

Post by Jeff Pyle
In my configuration there is no NAT whatsoever. Is there a way to

disable NAT traversal completely, thereby working around this issue for the
time being?
I should also add sipX being behind a firewall.
Joegen,
Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.
In my configuration there is no NAT whatsoever. Is there a way to
disable NAT traversal completely, thereby working around this issue for the
time being?
- Jeff

Post by Joegen Baclor
Jeff, good bug reporting!
By late negotiation, do you mean INVITE with no SDP? There is a known
issue with NAT traversal plugin not being able to handle this properly. If
you don't mind, please open a tracker in jira and attach packet captures.
Hello,
At the end of another thread<http://list.sipfoundry.org/archive/sipx-users/msg41614.html>Tony suggested I try attended transfers and some other parking related
operations against an Adtran TA900-series gateway. It seemed there had
been some friction here in the past.
I was able to test attended and unattended transfers with sipX 4.6 on
an Adtran TA908E. The global config option "voice transfer-mode network"
is required to support REFERs. Without it the results will be undesirable.
With that line, however, unattended transfers worked just fine
Attended transfers yielded no audio when the transfer completed if the
This is the SDP of the INVITE with Replaces that arrives at the Adtran
v=0

Post by Jeff Pyle
o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000

This is correct, telling the Adtran to send audio to 172.21.201.60 (c=
line) on port 2250 (m= line). 172.21.201.60 is the IP address of the
Polycom who was the A-leg of the call.
As part of some DSP cleanup ops the Adtran starts a reINVITE
transaction with late negotiation as soon as the above transaction is
completed. The offer SDP on sipX's 200 OK of that transaction looks like
v=0

Post by Jeff Pyle
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54

Notice the c= and m= lines have changed. sipX is now telling the
Adtran to send audio to 192.168.54.46, the IP address of the sipX instance
itself. This is why the A-leg Polycom at 172.21.201.60 doesn't receive any
audio after the transfer - sipX told the Adtran to send the audio elsewhere.
Any idea why sipX might do that?
As a bandaid, one can prevent the Adtran from sending the reINVITE by
adding "no prefer reinvite-without-sdp" to the voice trunk configured to
talk to sipX. This command is available only in prerelease code at the
moment. I believe it will be GA by the end of the month.
- Jeff
_______________________________________________
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Todd Hodgen]

Jeff, I think the confusion is that some sip components are on the
192.168.53.x network, while others are on 172.21.201.x network. In your
description below, you state "which routes", which is indicating there is a
router on the network, and the IP addressing would indicate they are on
different networks. A router is required to route from one network to the
other network.



NAT would be associated with a router - hence the reason why the questions
around where the router is.



one Polycom extension 1821 at 172.21.201.39 calls another, 7821, at
172.21.201.60. 7821 does an attended transfer to 2164550549, which routes
through the Adtran gateway at 192.168.53.11. The sipX system itself is at
192.168.54.46.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Jeff Pyle
Sent: Tuesday, September 25, 2012 10:35 AM
To: Joegen Baclor
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Incorrect SDP from sipX after xfer completion



Joegen,



I fully understand my network so I don't see where the problem is. :)



All the details, including an adequate topology description, are now in
XX-10464 <http://track.sipfoundry.org/browse/XX-10464> .




- Jeff



On Tue, Sep 25, 2012 at 12:57 PM, Joegen Baclor <***@ezuce.com> wrote:

Jeff,

I might be missing something but the SDP you pasted



o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54



172.21.201.60 being the original IP of the polycom

and

192.168.54.46 being the IP of sipX

I assumed that there is a firewall linking these two networks. Maybe a
packet capture and a topology description would save us the need to
speculate much :-)





On 09/26/2012 12:45 AM, Jeff Pyle wrote:

Joegen,



In my case all the SIP-speaking components are directly routable to each
other with no firewalls and therefore no NAT in between. I don't understand
what you mean by "sipX being behind a firewall". Is that relevant to the
NAT traversal issue you mentioned?





- Jeff

Post by Jeff Pyle
In my configuration there is no NAT whatsoever. Is there a way to

disable NAT traversal completely, thereby working around this issue for the
time being?

I should also add sipX being behind a firewall.




On 09/26/2012 12:15 AM, Jeff Pyle wrote:

Joegen,



Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.



In my configuration there is no NAT whatsoever. Is there a way to disable
NAT traversal completely, thereby working around this issue for the time
being?





- Jeff





On Tue, Sep 25, 2012 at 12:09 PM, Joegen Baclor <***@ezuce.com> wrote:

Jeff, good bug reporting!

By late negotiation, do you mean INVITE with no SDP? There is a known issue
with NAT traversal plugin not being able to handle this properly. If you
don't mind, please open a tracker in jira and attach packet captures.



On 09/25/2012 11:57 PM, Jeff Pyle wrote:

Hello,



At the end of another thread
<http://list.sipfoundry.org/archive/sipx-users/msg41614.html> Tony
suggested I try attended transfers and some other parking related operations
against an Adtran TA900-series gateway. It seemed there had been some
friction here in the past.



I was able to test attended and unattended transfers with sipX 4.6 on an
Adtran TA908E. The global config option "voice transfer-mode network" is
required to support REFERs. Without it the results will be undesirable.
With that line, however, unattended transfers worked just fine



Attended transfers yielded no audio when the transfer completed if the
Adtran is the C-leg of the transfer. Here's why:



This is the SDP of the INVITE with Replaces that arrives at the Adtran from
sipX to wrap up the transfer:



v=0
o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000



This is correct, telling the Adtran to send audio to 172.21.201.60 (c= line)
on port 2250 (m= line). 172.21.201.60 is the IP address of the Polycom who
was the A-leg of the call.



As part of some DSP cleanup ops the Adtran starts a reINVITE transaction
with late negotiation as soon as the above transaction is completed. The
offer SDP on sipX's 200 OK of that transaction looks like this:



v=0
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54



Notice the c= and m= lines have changed. sipX is now telling the Adtran to
send audio to 192.168.54.46, the IP address of the sipX instance itself.
This is why the A-leg Polycom at 172.21.201.60 doesn't receive any audio
after the transfer - sipX told the Adtran to send the audio elsewhere.



Any idea why sipX might do that?



As a bandaid, one can prevent the Adtran from sending the reINVITE by adding
"no prefer reinvite-without-sdp" to the voice trunk configured to talk to
sipX. This command is available only in prerelease code at the moment. I
believe it will be GA by the end of the month.





- Jeff

[Jeff Pyle]

Hi Todd,

Understandable.

We have a large, private WAN. Routers? Absolutely. Some are Cisco, some
are Juniper, some are pure linux. But in no place are there are access
lists, NAT, etc. All connectivity is completely open. None of the routers
look any deeper than layer 3. In other words, they're just routers acting
as routers, not routers acting as firewalls.

The sipX system is 192.168.*54*.46, at the data center. The Adtran gateway
is 192.168.*53*.11, at the business office half an hour away. The two
Polycoms involved in the test are within 172.21.201.0/24, a test lab in a
different county. Each network represents different physical location.
(There are test devices on two other networks in two different counties
not even involved in this call flow.) As complicated as that may be, none
of the complexities have any bearing on sipX. As far as SIP is concerned
one can consider this to be a simple single-LAN design because there are no
access restrictions among the nodes.

Thanks for forcing me to clarify these details. I joke about understanding
my network, and while that may be true most days, sometimes I'm not always
the best at communicating it to others when necessary.


- Jeff

Post by Todd Hodgen
Jeff, I think the confusion is that some sip components are on the
192.168.53.x network, while others are on 172.21.201.x network. In your
description below, you state “which routes”, which is indicating there is a
router on the network, and the IP addressing would indicate they are on
different networks. A router is required to route from one network to the
other network. ****
** **
NAT would be associated with a router – hence the reason why the questions
around where the router is.****
** **
one Polycom extension 1821 at 172.21.201.39 calls another, 7821, at
172.21.201.60. 7821 does an attended transfer to 2164550549, which routes
through the Adtran gateway at 192.168.53.11. The sipX system itself is at
192.168.54.46.****
** **
*Sent:* Tuesday, September 25, 2012 10:35 AM
*To:* Joegen Baclor
*Cc:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Incorrect SDP from sipX after xfer completion*
***
** **
Joegen,****
** **
I fully understand my network so I don't see where the problem is. :)****
** **
All the details, including an adequate topology description, are now in
XX-10464 <http://track.sipfoundry.org/browse/XX-10464>.****
- Jeff****
** **
****
Jeff,
I might be missing something but the SDP you pasted****
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54
****
172.21.201.60 being the original IP of the polycom
and
192.168.54.46 being the IP of sipX
I assumed that there is a firewall linking these two networks. Maybe a
packet capture and a topology description would save us the need to
speculate much :-)****
On 09/26/2012 12:45 AM, Jeff Pyle wrote:****
Joegen, ****
** **
In my case all the SIP-speaking components are directly routable to each
other with no firewalls and therefore no NAT in between. I don't
understand what you mean by "sipX being behind a firewall". Is that
relevant to the NAT traversal issue you mentioned?****
** **
** **
- Jeff
****
****

Post by Jeff Pyle
In my configuration there is no NAT whatsoever. Is there a way to

disable NAT traversal completely, thereby working around this issue for the
time being?****
I should also add sipX being behind a firewall. ****
On 09/26/2012 12:15 AM, Jeff Pyle wrote:****
Joegen, ****
** **
Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.****
** **
In my configuration there is no NAT whatsoever. Is there a way to disable
NAT traversal completely, thereby working around this issue for the time
being?****
** **
** **
- Jeff****
****
****
Jeff, good bug reporting!
By late negotiation, do you mean INVITE with no SDP? There is a known
issue with NAT traversal plugin not being able to handle this properly. If
you don't mind, please open a tracker in jira and attach packet captures.
****
On 09/25/2012 11:57 PM, Jeff Pyle wrote:****
Hello, ****
** **
At the end of another thread<http://list.sipfoundry.org/archive/sipx-users/msg41614.html>Tony suggested I try attended transfers and some other parking related
operations against an Adtran TA900-series gateway. It seemed there had
been some friction here in the past.****
** **
I was able to test attended and unattended transfers with sipX 4.6 on an
Adtran TA908E. The global config option "voice transfer-mode network" is
required to support REFERs. Without it the results will be undesirable.
With that line, however, unattended transfers worked just fine****
** **
Attended transfers yielded no audio when the transfer completed if the
Adtran is the C-leg of the transfer. Here's why:****
** **
This is the SDP of the INVITE with Replaces that arrives at the Adtran
from sipX to wrap up the transfer:****
** **
v=0
o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000****
** **
This is correct, telling the Adtran to send audio to 172.21.201.60 (c=
line) on port 2250 (m= line). 172.21.201.60 is the IP address of the
Polycom who was the A-leg of the call.****
** **
As part of some DSP cleanup ops the Adtran starts a reINVITE transaction
with late negotiation as soon as the above transaction is completed. The
offer SDP on sipX's 200 OK of that transaction looks like this:****
** **
v=0
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54****
** **
Notice the c= and m= lines have changed. sipX is now telling the Adtran
to send audio to 192.168.54.46, the IP address of the sipX instance itself.
This is why the A-leg Polycom at 172.21.201.60 doesn't receive any audio
after the transfer - sipX told the Adtran to send the audio elsewhere.****
** **
Any idea why sipX might do that?****
** **
As a bandaid, one can prevent the Adtran from sending the reINVITE by
adding "no prefer reinvite-without-sdp" to the voice trunk configured to
talk to sipX. This command is available only in prerelease code at the
moment. I believe it will be GA by the end of the month.****
** **
** **
- Jeff****
** **
** **
** **
_______________________________________________****
sipx-users mailing list****
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
** **
** **
** **
** **
** **
** **
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Joegen Baclor]

Thanks Jeff. Will look at it the soonest.

Post by Jeff Pyle
Joegen,
I fully understand my network so I don't see where the problem is. :)
All the details, including an adequate topology description, are now
in XX-10464 <http://track.sipfoundry.org/browse/XX-10464>.
- Jeff
Jeff,
I might be missing something but the SDP you pasted
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54
172.21.201.60 being the original IP of the polycom
and
192.168.54.46 being the IP of sipX
I assumed that there is a firewall linking these two networks.
Maybe a packet capture and a topology description would save us
the need to speculate much :-)

Post by Jeff Pyle
Joegen,
In my case all the SIP-speaking components are directly routable
to each other with no firewalls and therefore no NAT in between.
I don't understand what you mean by "sipX being behind a
firewall". Is that relevant to the NAT traversal issue you
mentioned?
- Jeff
On Tue, Sep 25, 2012 at 12:42 PM, Joegen Baclor

Post by Jeff Pyle

Post by Jeff Pyle
In my configuration there is no NAT whatsoever. Is there

a way to disable NAT traversal completely, thereby working
around this issue for the time being?
I should also add sipX being behind a firewall.

Post by Jeff Pyle
Joegen,
Yes, exactly. INVITE with no SDP. I'll open a tracker shortly.
In my configuration there is no NAT whatsoever. Is there a
way to disable NAT traversal completely, thereby working
around this issue for the time being?
- Jeff
On Tue, Sep 25, 2012 at 12:09 PM, Joegen Baclor
Jeff, good bug reporting!
By late negotiation, do you mean INVITE with no SDP?
There is a known issue with NAT traversal plugin not
being able to handle this properly. If you don't mind,
please open a tracker in jira and attach packet captures.

Post by Jeff Pyle
Hello,
At the end of another thread
<http://list.sipfoundry.org/archive/sipx-users/msg41614.html>
Tony suggested I try attended transfers and some other
parking related operations against an Adtran
TA900-series gateway. It seemed there had been some
friction here in the past.
I was able to test attended and unattended transfers
with sipX 4.6 on an Adtran TA908E. The global config
option "voice transfer-mode network" is required to
support REFERs. Without it the results will be
undesirable. With that line, however, unattended
transfers worked just fine
Attended transfers yielded no audio when the transfer
completed if the Adtran is the C-leg of the transfer.
This is the SDP of the INVITE with Replaces that
v=0
o=- 1348230370 1348230370 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
a=sendrecv
m=audio 2250 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
This is correct, telling the Adtran to send audio to
172.21.201.60 (c= line) on port 2250 (m= line).
172.21.201.60 is the IP address of the Polycom who was
the A-leg of the call.
As part of some DSP cleanup ops the Adtran starts a
reINVITE transaction with late negotiation as soon as
the above transaction is completed. The offer SDP on
v=0
o=- 1348230370 1348230371 IN IP4 172.21.201.60
s=Polycom IP Phone
c=IN IP4 172.21.201.60
t=0 0
m=audio 30248 RTP/AVP 9 0 8 18 101
c=IN IP4 192.168.54.46
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54
Notice the c= and m= lines have changed. sipX is now
telling the Adtran to send audio to 192.168.54.46, the
IP address of the sipX instance itself. This is why the
A-leg Polycom at 172.21.201.60 doesn't receive any
audio after the transfer - sipX told the Adtran to send
the audio elsewhere.
Any idea why sipX might do that?
As a bandaid, one can prevent the Adtran from sending
the reINVITE by adding "no prefer reinvite-without-sdp"
to the voice trunk configured to talk to sipX. This
command is available only in prerelease code at the
moment. I believe it will be GA by the end of the month.
- Jeff
_______________________________________________
sipx-users mailing list
List Archive:http://list.sipfoundry.org/archive/sipx-users/