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

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 09 Mar 2008 13:02:45 -0400

I really like this draft. I think it makes a lot of sense to do this, 
and there are also other useful applications of it. Anywhere that has 
low-bandwidth IP or low QoS IP, but enough for signaling, this can make 
sense.

I think the draft could benefit from some explanation of WHY to do this. 
For the various cases, why not just use pure PSTN? What value does the 
SIP bring? I think it helps handoff, it can bring additional features 
that SIP signaling brings (IM, presence, etc.). Its worth mentioning 
these and giving specific examples.

On the requirements: I'd also add a requirement that it be possible to 
negotiate who makes the PSTN call. Directionality is hugely important 
since costs can vary a lot depending on who makes the call. Also I'd 
suggest a requirement that says it works with any kind of PSTN interface 
- from analog to ss7. So the PSTN mechanism cannot rely on 
access-specific features.

For the protocol mechanism, I pretty much agree with what you proposed, 
with a few differences.

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.

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.

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.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 17 Mar 2008 10:46:47 +0200

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:

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

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

> 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

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