Subject: [Sip] a middle ground approach for knowing AOR of a gruu

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Feb 2005 00:17:27 -0500

We had a long discussion in another thread about whether or not we had 
an additional requirement to allow the recipient of a GRUU to be able to 
determine the AOR associated with that gruu. This seemed to be an issue 
for systems that generate call logs or bills, since you'll have these 
entries that are meaningless.

Though I didnt make any changes to gruu in order to meet this 
requirement, there may be a simple approach that we can provide that 
fits with the current gruu mechanism.

The spec is clear that there are no constraints on how a domain 
constructs a gruu. The appendix includes a few sample algorithms (though 
I'll note one of them is broken...). As such, there is nothing wrong 
with a domain constructing a gruu by including the instance ID and AOR 
in the clear in the user part of the URI:

sip:jdrosen.instance.00sd8ggdgdasd===[email-masked]

for example. Thus, we could list such a technique as a viable approach, 
and recommend that a particular means of encoding the URI be used in 
order to allow other entities to extract the aor.

Thus, we would have a way for the recipient of a domain to get a hint 
about the possible AOR (no guarantee though), without changing the 
mechanism at all.

Would that represent a reasonable compromise?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "kkuei" <[email-masked]>
Date: Thu, 24 Feb 2005 15:25:52 +0800

I'm reading rfc3264 (offer/answer model with SDP). May I ask you a question 
about that? 

in 5.1, it says: 
  For sendrecv RTP 
  streams, the payload type numbers indicate the value of the payload 
  type field the offerer expects to receive, and would prefer to send. 
  However, for sendonly and sendrecv streams, the answer might indicate 
  different payload type numbers for the same codecs, in which case, 
  the offerer MUST send with the payload type numbers from the answer. 

in 6.1, it says: 
  In the case of RTP, if a particular codec was referenced with a 
  specific payload type number in the offer, that same payload type 
  number SHOULD be used for that codec in the answer.  Even if the same 
  payload type number is used, the answer MUST contain rtpmap 
  attributes to define the payload type mappings for dynamic payload 
  types, and SHOULD contain mappings for static payload types.  The 
  media formats in the "m=" line MUST be listed in order of preference, 
  with the first format listed being preferred.  In this case, 
  preferred means that the offerer SHOULD use the format with the 
  highest preference from the answer. 

My question is, the payload type number in answer may be different than in 
offer. Here is the case: 

1. Offer 
PCM-WB: 98 
ISAC: 101 
iLBC: 102 

2. Answer 
iLBC: 98 

This means both parties agreed to use iLBC. 
My question is , what payload type number should be use in constructing RTP 
pkts (in both direction). 

In sec5.1, it says offerer MUST respect the answer. It MUST put "98" in 
payload type number in RTP (offerer->answerer). 

But what about in answerer ?? should it respect the offer? which payload type 
number (102 or 98) it should put in RTP (answerer->offerer)?? 

I tried to read the rfc3264 for several times.. but still not quite clear. Do 
u have any idea about that? 

-- 
Kevin Kuei

---

From: Rajeew Kumar Singh <[email-masked]>
Date: Thu, 24 Feb 2005 13:33:28 +0530

Hi,
 Here is my understanding on your offer-answer scenerio
Let us suppose two UA having said capabilities

UA-A
	          PT
PCM-WB:        98
ISAC:             101
iLBC:              102

UA-B		PT
	iLBC:    98

Note : All PT falls under dynamic payload range

Two possible cases for offer-answer

Case1: If offer is from UA-A to UA-B
	A---------------Offer1-----------------> B
	A <------------Answer1--------------B
Offer1:
PCM-WB: 98
ISAC: 101
iLBC: 102

Then Answer1 will be
iLBC: 102

Here UA-B will change the dynamic paylod type for iLBC to 102 from 98 and
use this in RTP packets.
Both UA-A and UA-B will use PT 102 in RTP Packets

Case2: If the offer is from UA-B to UA-A

 	A<-------------------------Offer2------------------B
	A-------------------------Answer2--------------->B

Offer2:
iLBC:    98

Then answer2 will be
iLBC:    98

Here UA-A will change the dynamic payload type for iLBC to 98 from 102 and
will use this PT 98 in RTP packets.
Both UA will use PT 98 in RTP Packets.

Hope it will help you.

Regards
Rajeew Kumar Singh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of kkuei
Sent: Thursday, February 24, 2005 12:56 PM
To: Jonathan Rosenberg; [email-masked]
Subject: [Sip] rfc3264 question

in 5.1, it says:
  For sendrecv RTP

in 6.1, it says:

1. Offer
PCM-WB: 98
ISAC: 101
iLBC: 102

2. Answer
iLBC: 98

But what about in answerer ?? should it respect the offer? which payload
type
number (102 or 98) it should put in RTP (answerer->offerer)??

I tried to read the rfc3264 for several times.. but still not quite clear.
Do
u have any idea about that?

--
Kevin Kuei

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Feb 2005 08:44:02 -0500

I find this sub-optimal from a general design point of view. I thought 
we have had a general preference for being explicit about semantics, 
rather than overloading other elements or mechanisms. (See discussions 
on INFO and other similar topics.) I think many of the proposed labeling 
mechanisms would work and supporting at least one, even if somewhat 
arbitrarily selected, will get us to do the right thing in the majority 
of cases.

This is particularly important since this is not just a local matter, 
i.e., other parties not familiar with the conventions of the sending 
side will need to be able to robustly extract this information.