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

[Haruki Izumikawa <[e-mail]>]

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.


 > 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 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.


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