Re: [MMUSIC] comments on draft-garcia-mmusic-sdp-cs-00

[Miguel Garcia <Miguel.Garcia at nsn.com>]

Jonathan:

Thanks for your comments, that we will take into account in the next 
version of the draft.

A few points that require further discussion:

Jonathan Rosenberg wrote:
> Firstly, I'd suggest that the network name is not "CS". Its "PSTN". THe 
> reason is, I can think of use cases where we actually USE sip itself to 
> set up the pstn bearer. For example, consider a call agent that sets up 
> the bearer by sending an INVITE to a local pstn gateway. So the access 
> doesn't have to be circuit per se - it just needs to go to the PSTN.

OK, I don't have a problem changing the string to "PSTN".

Does the comment also apply to the <proto> subfield in the m= line? I 
assume it does.


> 
> I'm not sure listing codecs makes sense. The reason is that, the codec 
> is usually hidden - certainly hidden from the far end. So if I make a 
> call from my pstn landline to your mobile, YOU may be using AMR but its 
> g711 to me. Indeed, its actually analog voice to me, its the switch that 
> converts to 711. So I don't think it makes any sense at all to include 
> codecs in the m-lines as they are always only locally significant.

That is correct. In the PSTN there might be a few transcoding entities 
and they are not visible at the SIP level. There is one use case that 
came to my mind: If I offer you a PSTN bearer and an RTP bearer, and I 
describe wideband audio codecs in RTP but AMR in the PSTN bearer, then 
you could select the RTP bearer because of the higher quality of the codec.

In most cases, I agree that signaling the codec makes no difference, and 
it can just merely be considered as a smooth hint, which may differ from 
the end result. This is the reason why the codec can be empty (with a 
dash "-").

I don't have a strong opinion on this topic, so if we believe that the 
use case is not significant enough, we can remove it and leave the codec 
empty.

> 
> Probably the biggest technical issue is correlation - how to link the 
> incoming pstn call with the SIP signaling. There are several options and 
> they go from awful (dtmf) to just OK (caller ID) to really nice (ISDN 
> UUI indicators). The draft clearly needs to discuss this problem and 
> propose specific mechanisms, possibly more than one depending on the access.

Agreed. We will add a further discussion.

With respect the actual mechanisms, the draft only discusses the caller 
ID. UUI will work. I am assuming that you would like to send some sort 
of magic cookie in SDP that is then echoed in the actual User-to-User 
Information Element.

With respect the DTMF option, I don't think this will work, because DTMF 
are sent in the user plane, so, you need to answer the call prior to 
reception of DTMF tones, and at that time you already need to know 
whether this is a call linked to the SDP or not.

/Miguel

> 
> Thanks,
> Jonathan R.

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic