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
>
> -----Original Message-----
>
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>
> Sent: 2008年6月4日 20:45
>
> To: Attila Sipos
>
> Cc: Yuantao Zhang; [email protected]; [EMAIL PROTECTED]
>
> Subject: Re: [Sip] What is the port number in "Invite" request-line? Thanks
>
>
>
> Attila Sipos wrote:
>
>>
>
>> It is possible to have two instances of a UA (for example) on one unit.
>
>>
>
>> So using the port is theoretically one way to differentiate between
>
>> instances.
>
>>
>
>> It's not useless. If you get a Contact header with a port then you have
>
>> to send to that port (discounting NAT traversal scenarios) otherwise
>
>> everything will break.
>
>>
>
>> > >Or is the port number is which the UAS is listening to? How the UAC
>
>> knows it is 5555 if so?
>
>>
>
>> A UAC might not know but a proxy/registrar might - for example if a user
>
>> was registered with
>
>> the Contact as port 5555, then requests to that user will get forwarded
>
>> to port 5555.
>
>> Another user using, for example, port 5556 will register using a Contact
>
>> with 5556
>
>> and so will receive requests to that port.
>
> Right. This illustrates a good point:
>
> In general a UAC should not be expected to know "what port a UAS listens
>
> on". All A UAC should be doing is sending requests to URIs that it has
>
> been given. If the URI it is given contains a port number, then it
>
> should honor that.
>
> This gets bent out of shape a bit by numeric dialing, where the UAC is
>
> only given a dial string and must derive a URI from it. The "standard"
>
> way to do this is via ENUM, where effectively the numeric address is
>
> looked up in a DB to obtain a URI. In that case again the UAC has been
>
> "given" the URI, which may have a port or not.
>
> In the non-standard but common case where the UAC *constructs* a URI
>
> from a dial string, the UAC must still be *told* what to use for the
>
> remainder of the URI.
>
> Paul
>
> ***From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of* Yuantao Zhang
> ***Sent:* 04 June 2008 11:10
> ***To:* [email protected]; [EMAIL PROTECTED]
> ***Subject:* [Sip] What is the port number in "Invite" request-line? Thanks
>
> Dear all
>
> INVITE sip:[EMAIL PROTECTED] SIP/2.0:5555
>
> INVITE sip:[EMAIL PROTECTED] SIP/2.0
>
> Above are 2 “Invite” request-line examples. In example one, it indicates
> a port number, 5555. What does the port number mean?
>
> Is it the port number of SIP proxy? Why we include port number here? The
> SIP proxy(biloxi.com) application layer who receives this "Invite"
> should receive this via port 5555 from lowe layer(UDP). Therefore, The
> SIP proxy(biloxi.com) application layer already know the port is 5555.
> Actualy, the SIP proxy application layer keeps listening port 5555.
>
> The second “Invite” request-line example is from RFC3261 and does not
> include port number. Can I say the port number is useless? So why
> example one includes a useless part in “Invite” request-line URL?
>
> Or is the port number is which the UAS is listening to? How the UAC
> knows it is 5555 if so?
>
> Any standard on this port number issue? Thanks.
>
> Best regards
>
> Steven
>
_______________________________________________
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
