Yuantao Zhang wrote:
> 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
Yes of course I can give an example. If the message contains a Route
header, then it will be sent to the address (and port if present) in the
top Route header. Meanwhile the address (and port) in the R-URI remain,
and will *eventually* be used to route the message when the Route header
has been exhausted.
Paul
> Best regards
> Yuantao
>
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: 2008年6月9日 19:53
> To: Yuantao Zhang
> Cc: [email protected]; [EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]
>> Sent: 2008年6月6日 19:55
>> To: Yuantao Zhang
>> Cc: Attila Sipos; [email protected]; [EMAIL PROTECTED]
>> 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:[EMAIL PROTECTED]:5555 SIP/2.0 *ß------------
>>> Via: SIP/2.0/UDP 192.168.100.3:5060;rport;branch=z9hG4bK27195
>>> From: <sip:[EMAIL PROTECTED]>;tag=27266
>>> To: <sip:[EMAIL PROTECTED]:5555>
>>> Call-ID: [EMAIL PROTECTED]
>>> CSeq: 20 INVITE
>>> Contact: <sip:[EMAIL PROTECTED]: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
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
