>>> 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.<[email protected]> 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 
</[email protected]>Contact: <sip:[email protected]:5070 but 
that is where sipxbridge will send responses too...and as such the 5080/5060 is 
not related.
<[email protected]>
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.

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.


</[email protected]>
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to