[EMAIL PROTECTED] wrote:
> 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?
IMO this is an area that has been insufficiently considered.
The new path and the old path may be different, and so may have
differing latencies. So, the sender may have smoothly transitioned from
the old stream to the new one, but on the receiving side data may be
received on the new one before all data has been received on the old
one. To avoid missing any data in this case it would be necessary to
read out all from the old stream before processing the new stream. But
of course you don't know when you have it all from the old one.
Ignoring the old stream as soon as data arrives on the new stream would
in this case result is missing some data. For RTP, this may not be
enough for anyone to care, or even notice, but it is a loss. If this
were MSRP, it could result in losing whole IM messages, which would not
be good.
Some time ago, someone wrote a draft regarding handoff of video streams.
Because of the way these are encoded you may have to have received quite
a bit of one of these streams before you can display anything. So they
were advocating an explicit make-before-break strategy where data would
be transmitted redundantly on both streams for a time. That of course is
an entirely different strategy for switching from one to another.
Thanks,
Paul
> 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
