Re: [Sipping] Request for Open discussion about SIP mobility

[Haruki Izumikawa <[e-mail]>]

Paul,

Thank you for your prompt reply.


Paul Kyzivat wrote:
> 
> 
> Haruki Izumikawa wrote:
>> Hello Paul,
>>
>> I should like to thank you for your useful comments.
>>
>>  > The a=bicast approach only seems sufficient when
>>  > there is a single media stream to deal with.
>>  > If there are multiple media streams, then it gets
>>  > tricky to match them all up. The grouping framework
>>  > is a better solution. It would be helpful to see
>>  > an example where there there are
>>  > two media streams that each need to be bicast.
>>
>> [HI] You are quite right. In the a=bicast approach, it indeed gets 
>> difficult to associate one media stream with others when there are 
>> multiple media streams. As you pointed out, the extension of grouping 
>> framework seems to be suitable.
>>
>>
>>  > One thing that isn't clear to me is now the recipient
>>  > of the bicast traffic matches up the two streams and
>>  > decides what media to render. Is there enough
>>  > information in RTP, even when transcoding has been
>>  > performed on one or both of the streams, to allow
>>  > this to work reliably?
>>  > (Disclaimer - I know little about RTP.)
>>
>> [HI] When I made prototype software regarding SIP-based bicasting, I 
>> adopted a cross-layer approach. In fact, as you concerned, I think RTP 
>> layer itself cannot distinguish which media streams to be rendered. In 
>> the prototype software, media streams from an I/F of targeted network 
>> are rendered.
> 
> Perhaps it doesn't matter which is rendered as long as both are being 
> received adequately. But if one stops being received, either because 
> connectivity is lost or because the handoff back to unicast is 
> performed, if the remaining stream isn't the one that was being 
> rendered, then one needs to be able to discern where in that stream to 
> begin rendering. Is some of it duplicating data that has already been 
> rendered?
> 
> I guess for RTP this can be handled via the time base if the streams 
> remain synchronized after possibly going through a transcoder. Is that 
> expected?

[HI] Yes. Since the independent multimedia streams are transcoded, their 
RTP timestamps cannot be synchronozed and compared. So, in the prototype 
software, the transcoder associates the time for the synchronous 
rendering with the RTP header of the respective streams. In addition, an 
intra-frame is also marked on the RTP header if MPEG or H.264 is used as 
the video compression technology.



>>  > And related to that - what about non-RTP media?
>>  > This same scenario is applicable to less conventional
>>  > media, such as IM. While technically it is possible
>>  > to follow the pattern you have outlined to establish
>>  > bicast MSRP, the identification of duplicate messages
>>  > will require a different solution.
>>
>> [HI] I think the bicasting solution is needed for realtime multimedia 
>> streams in which re-transmission cannot be acceptable. Therefore, I 
>> don't know some services such as IM or file transfer using MSRP need 
>> bicasting support. In fact, I haven't considered the concern you 
>> pointed out. I'm going to have to weigh this concern more carefully. 
>> Thank you for bringing this matter up.
> 
> I guess it depends on what you mean by "acceptable".
> If you move from wifi to cellular access while IMing, I will not be 
> happy if some IMs from you are dropped or duplicated.
> 
> In fact, I think this is more noticable for IM than for voice. With 
> voice a few dropped packets may cause a "glitch" but probably will not 
> create a significant loss of information. But a single dropped IM can be 
> a large loss of information.
> 
> And now people are talking about using MSRP for real time text as well.
> 
> So while it is perhaps of lower priority and interest, I think media 
> such as MSRP are worthy of some consideration.

[HI] I understand an importance of dealing with IM. I'll take the media 
such as MSRP into account. Thanks.

Regards,

Haruki


> 
>>  > I also would be interested to hear your thoughts about
>>  > the urgency of cutover and the mechanics of doing it.
>>  > I know you state an assumption that there is some
>>  > overlap in coverage of the two access networks. And
>>  > without that things get very difficult. But the overlap
>>  > may not be very extensive, so it may be wise to
>>  > quickly get from one to the other entirely - for
>>  > signaling as well as media. So for instance it might be
>>  > desirable to switch the signaling path to AN2 ASAP,
>>  > before bicasting ceases. Or, it may be prudent
>>  > to find a way to maintain "bicast" signaling paths
>>  > as well for the time when it is uncertain which AN might
>>  > remain available.
>>
>> [HI] As you pointed out, I should consider the case where a terminal 
>> loses a connection of AN1 during handoff from AN1 to AN2. In my 
>> opinion, same as your second view, it could be preferable to maintain 
>> bicast signaling paths on a stable wireless system such as cellular. 
>> In addition, related to that, I think it is important to consider a 
>> ping-pong movement. Regarding both of them, it would be necessary to 
>> take into consideration an underlying radio behavior, e.g., 
>> penetration (coverage area) and fluctuation. This kind of issue is 
>> important to realize an intelligent mobility service in market.
> 
> Thanks,
>     Paul
> 
>> Best wishes,
>>
>> Haruki
>>
>>
>> Paul Kyzivat wrote:
>>> Interesting document. I am happy to see more exploration of the 
>>> subject area.
>>>
>>> The a=bicast approach only seems sufficient when there is a single 
>>> media stream to deal with. If there are multiple media streams, then 
>>> it gets tricky to match them all up. The grouping framework is a 
>>> better solution. It would be helpful to see an example where there 
>>> there are two media streams that each need to be bicast.
>>>
>>> One thing that isn't clear to me is now the recipient of the bicast 
>>> traffic matches up the two streams and decides what media to render. 
>>> Is there enough information in RTP, even when transcoding has been 
>>> performed on one or both of the streams, to allow this to work 
>>> reliably? (Disclaimer - I know little about RTP.)
>>>
>>> And related to that - what about non-RTP media? This same scenario is 
>>> applicable to less conventional media, such as IM. While technically 
>>> it is possible to follow the pattern you have outlined to establish 
>>> bicast MSRP, the identification of duplicate messages will require a 
>>> different solution.
>>>
>>> I also would be interested to hear your thoughts about the urgency of 
>>> cutover and the mechanics of doing it. I know you state an assumption 
>>> that there is some overlap in coverage of the two access networks. 
>>> And without that things get very difficult. But the overlap may not 
>>> be very extensive, so it may be wise to quickly get from one to the 
>>> other entirely - for signaling as well as media. So for instance it 
>>> might be desirable to switch the signaling path to AN2 ASAP, before 
>>> bicasting ceases. Or, it may be prudent to find a way to maintain 
>>> "bicast" signaling paths as well for the time when it is uncertain 
>>> which AN might remain available.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>
>>>
>>> Haruki Izumikawa wrote:
>>>> Hello folks,
>>>>
>>>> I'd like to have an open discussion about SIP-based mobility in this 
>>>> ML.
>>>> Mobility managements using SIP have been actively studied and developed
>>>> worldwide since "Mobility Support Using SIP" (by Elin and Henning) was
>>>> published. SIP-based mobility would have strong advantages such as its
>>>> great affinity for an application as well as flexibility, i.e., 
>>>> terminal
>>>> mobility can be optimally supported independent from underlying 
>>>> network.
>>>> On the other hand, despite many advantages, it is not used for
>>>> large-scale commercial yet. In addition, the discussion about SIP-based
>>>> mobility in IETF seems to be undynamic.
>>>> These days, a multimode terminal is getting popular. Each access
>>>> networks, e.g., cellular and WLAN, have different characteristics in
>>>> terms of throughput or delay. In such a heterogeneous network, SIP
>>>> becomes more useful tool for mobility management because of its
>>>> flexibility. The quality of a multimedia service can be adaptively
>>>> changed in accordance with a nature of an access networks even after
>>>> changing an access network. I think it is time to resume discussing
>>>> about SIP-based mobility. For your information, I have submitted I-D
>>>> regarding seamless session handoff by SIP-based bicasting.
>>>> http://www.ietf.org/internet-drafts/draft-izumikawa-sipping-sipbicast-01.txt 
>>>>
>>>> I would be happy to hear frank opinions of SIP specialists.
>>>>
>>>> Best regards,
>>>>
>>>> Haruki
>>>>
>>>>
>>
> 

-- 
Haruki Izumikawa
KDDI R&D Laboratories
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP