On 1/27/2011 3:02 PM, Matt White wrote:
>>> Tony Graziano
>> When an invite comes from the provider and says the address and
port "123.456.789.10:5080" and it needs to say instead
>>"123.456.789.10:5060", its not the PACKET that needs to be
translated or the address, its what is INSIDE the header, not
>>the actual packet destination. This means something has to actually
take the header message and rewrite it with the
>>correct information. A simple PAT or NAT in a firewall is not going
to be able to do this in any event.01/27/11 3:44 PM
Made this new thread. I'm interested in the scenario you point out
here as I've never seen an second SBC required to translate 5060 to
5080 for sip trunking to work.
Where do you see this scenario occur?
A typical sip invite from an itsp to sipxbridge does not included the
port for the invite in the sip header. Thats why a simple port
forward/nat works without the need for an SBC outside of sipxbridge.
The invite does not include that info typically.
For example, here is an example taken from his packet trace as an
example of a normal invite.
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 172.30.216.62:5070;branch=z9hG4bK4o0sud00boih8p0ig5s1.1
From: "WIRELESS CALLER"
<sip:[email protected];user=phone>;tag=1444716082-1296146110120-
To: "DSI HOLDING DSI TEST ENTERPRISE" <sip:[email protected]>
Call-ID: [email protected]
CSeq: 606735189 INVITE
Contact: <sip:[email protected]:5070;transport=udp>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept: multipart/mixed,application/media_control+xml,application/sdp
Supported:
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 209
Nowhere in the actual SIP info is the port where sipxbridge received
the info. The sip header does include where we respond with our
packets...in this case Contact: <sip:[email protected]:5070 but
that is where sipxbridge will send responses too...and as such the
5080/5060 is not related.
A simple port forward/NAT to translate the packet destination from
5060 to 5080 works fine for sip trunking becuase the port info is just
that...not in the sip header.
This is how I understood everything to work. We had detailed meetings
with verizon and they did packet captures on their end to verify
everything was behaving as it should. I had to provide wireshark samples
for about 60 different situations that covered far more scenarios than I
could have ever thought of. They then went in front of their technical
review board to see if they approved connecting this non-certified
device to to their Voip network. This was all with 4.0.4 and polycom
firmware 3.1.3c.
Do you see invites from a certain ITSP that puts the destination port
in the packet? I wonder how many providers do this? We only use about
4 or 5 providers will all are installs but have not seen this before.
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
