Hi Paul,
As you say, media may continue to arrive on the old port for a
time, but once there is media arriving on the new port one should
ideally stop listening/communicating over the old port, isn't it?
Section 8.3.1 Modifying Address, Port or Transport of RFC 3264 says
" The offerer SHOULD NOT cease listening for media on the old port until
the answer is received and media arrives on the new port."
So once there is a RTP packet on the new port/IP Address, there after
all the RTP packets will be arriving on new port/IP Address, and one can
cease listening on the old port/IP Address, right?
Thanks,
Bharat
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 06, 2008 5:40 PM
To: Rockson Li (zhengyli)
Cc: Bharat Sarvan (WT01 - Telecom Equipment);
[email protected]
Subject: Re: [Sip-implementors] SDP Query - reINVITE with IP Address
inconnection info field updated.
Rockson Li (zhengyli) wrote:
> Bharat,
>
> You are mostly correct.
> One point I want to add is you might get SDP answer in reliable
response instead of 200, though this is seldom used in real world, but
It's totally correct as per spec.
>
> You can also check out RFC3264 sec 8.3.1 Modifying Address, Port or
Transport
Agree.
There is a window during which one can't be certain which of the
addresses will be used. Specifically, from the moment the offer is sent
there is the possibility of receiving on the offered port. But one can't
be certain until at least after receiving the answer. Even then, because
the paths are different, media may continue to arrive at the old port
for a time.
This isn't much of a problem for audio, or probably for video either.
Typically you can just stop listening on the old port and start on the
new at some point, and not worry about packets lost if you didn't get
the timing just right. A few packets don't make that much difference.
But it *can* matter for some media. For instance, if you are using an
MSRP media stream for IM, then losing *one* message can be a problem. In
that case you will need to use a "make before break" strategy and
possibly merge media between the two streams.
Paul
> FYI
>
> -Rockson
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
> Sent: Wednesday, August 06, 2008 1:42 PM
> To: [email protected]
> Subject: [Sip-implementors] SDP Query - reINVITE with IP Address
inconnection info field updated.
>
> Hi all,
>
> Say we have call between Party A and Party B. When both
parties are in call, Party A sends out a re-INVITE to Party B updating
the IP Address in the connection information field in SDP.
>
>
>
> In the Initial SDP exchanged
>
> c: IN IP4 1.2.3.4
>
>
>
> In the re-INVITE sent
>
> c: IN IP4 5.6.7.8
>
>
>
> As far as I understand, once Party A receives a 200 OK from
the Party B for the re-INVITE sent; there won't be any media arriving on
the IP address 1.2.3.4. Further exchange of real time data will take
place at IP address 5.6.7.8. Am I right? Is there any RFC/Draft that
explains handling of this behavior?
>
>
>
>
>
> Thanks,
>
> Bharat
>
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
addressee(s) and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately and destroy all copies of this message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.
>
> www.wipro.com
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
