[SIPForum-discussion] [Sip] What is the port number in "Invite" request-line? Thanks

Yuantao Zhang yuantao.zhang at ericsson.com
Tue Jun 10 02:19:47 UTC 2008


Dear Paul 

Thanks for keeping answering my question. And it is happy to discuss with you. Could you give me a scenario that the port number in R-line and the lower layer UDP destination port are different? They are always same, aren't they? Thanks

Best regards
Yuantao


-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com] 
Sent: 2008年6月9日 19:53
To: Yuantao Zhang
Cc: sip at ietf.org; discussion at sipforum.org
Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks

OK, if you are talking about a case with a proxy/registrar, then when
the proxy does the translation, it does so by by takking the URI that
was provided in REGISTER and placing it into the R-URI. Then it routes
based on the revised message.

The whole system of routing sip messages is based on URIs. The URI *may*
contain a port, or the port may be discovered using DNS.

I guess you are proposing some entirely different system for managing
the routing of sip messages. But you are 8 or 9 years too late for that.

	Thanks,
	Paul

Yuantao Zhang wrote:
> ------------------     -------------------         -------------------
> 
> |UA1              |     |SIP proxy          |         |UA2                |
> 
> |IP:192.168.100.1|-----|IP: 192.168.100.2 |--------|IP: 192.168.100.3 |
> 
> |Port: 1111       |     |Port: 2222        |          |Port: 3333        |
> 
> ------------------      --------------------         -------------------
> 
> If UA1 makes call to UA2, UA1 should send the following message to the 
> SIP proxy:
> 
> ===============================================================
> 
> IP:
> 
> Src: 192.168.100.1
> 
> Dst: 192.168.100.2
> 
> ===============================================================
> 
> UDP:
> 
> Src port: 1111
> 
> Dst port: 2222                                                     !
> 
> ===============================================================
> 
> SIP:
> 
> INVITE sip:UA2 at 192.168.100.2:2222 SIP/2.0                          !
> 
> Via: SIP/2.0/UDP 192.168.100.1:1111;
> 
> ===============================================================
> 
> 
> Then SIP proxy sends the following message to UA2:
> 
> ===============================================================
> 
> IP:
> 
> Src: 192.168.100.2
> 
> Dst: 192.168.100.3
> 
> ===============================================================
> 
> UDP:
> 
> Src port: 2222
> 
> Dst port: 3333                                                     !
> 
> ===============================================================
> 
> SIP:
> 
> INVITE sip:UA2 at 192.168.100.2:3333 SIP/2.0                          !
> 
> Via: SIP/2.0/UDP 192.168.100.2:2222;
> 
> Via: SIP/2.0/UDP 192.168.100.1:1111;
> 
> ===============================================================
> 
> UAC(UA1) does not know the port of UAS(UA2). All the UAC needs to know 
> is the proxy's port. And the proxy knows all the ports of UAs under it 
> (UAs tell proxy when register). Therefore, the proxy does not care the 
> port number in the received "Invite" request-linen (because the port 
> number is proxy itself)
> 
> Therefore, the port number in the "Invite" request-line is always same 
> with the port number in the lower layer UDP. Why we insert redundant 
> information? How about we drop this redundant and confusing port number 
> in the URL? Please correct me if I am wrong. Thanks.
> 
> Best regards
> 
> Yuantao Zhang
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: 2008年6月6日 19:55
> To: Yuantao Zhang
> Cc: Attila Sipos; sip at ietf.org; discussion at sipforum.org
> Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks
> 
> The URI typically exists before the message is constructed. Then a
> 
> message is constructed and the URI included in it. The URI specifies
> 
> where the message is *intended* to go. And it might not go there
> 
> immediately. Instead it may first go to a proxy. When it gets there the
> 
> proxy needs to consult the R-URI to know where the message is intended
> 
> to go.
> 
> When the last hop to the final destination is made it is true that the
> 
> port number, and the ip address, may be redundant. But we don't expect
> 
> the intermediate nodes to remove the information. The recipient may do
> 
> as it wishes if it receives a request with addressing that is
> 
> inconsistent with where it is received.
> 
>         Paul
> 
> Yuantao Zhang wrote:
> 
>>  Dear all
> 
>>
> 
>>  Thanks for your reply. Please let me ask my question in another way.
> 
>>
> 
>>  ===============================================================
> 
>>
> 
>>  UDP:
> 
>>
> 
>>  Src port: 5060
> 
>>
> 
>>  Dst port: 5555        *ß------------
> 
>>
> 
>>  ===============================================================
> 
>>
> 
>>  SIP:
> 
>>
> 
>>  INVITE sip:123101 at 192.168.100.100:5555 SIP/2.0  *ß------------
> 
>>
> 
>>  Via: SIP/2.0/UDP 192.168.100.3:5060;rport;branch=z9hG4bK27195
> 
>>
> 
>>  From: <sip:123102 at 192.168.100.100>;tag=27266
> 
>>
> 
>>  To: <sip:123101 at 192.168.100.100:5555>
> 
>>
> 
>>  Call-ID: 24658 at 192.168.100.3
> 
>>
> 
>>  CSeq: 20 INVITE
> 
>>
> 
>>  Contact: <sip:123102 at 192.168.100.3:5060>
> 
>>
> 
>>  ===============================================================
> 
>>
> 
>>  The above "Invite" message is over UDP. In the UDP part (Transport
> 
>>  layer), the Destination port is 5555. In the SIP part (application
> 
>>  layer), the port in the "Invite" request-line URL is 5555 too. Both of
> 
>>  them are same. In which case the port in "Invite" request-line URL is
> 
>>  different from the Destination port in lower layer UDP? Furthermore, if
> 
>>  they are always same why we include redundant information (the port
> 
>>  number) in "Invite" request-line URL? What happens if the port in
> 
>>  "Invite" request-line URL is different from the Destination port in
> 
>>  lower layer UDP?
> 
>>
> 
>>  Thank you very much
> 
>>
> 
>>  Best Regards
> 
>>
> 
>>  Yuantao
> 
>>
> 




More information about the discussion mailing list