Subject: RE: [Dime] Diameter SIP app in AUTH48 state

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Tue, 14 Nov 2006 15:08:11 +0100

Hi Miguel,

I'm OK with the general intent. But I have a couple of questions:

- Is the wording "as the main SIP server for that user" refers to the function of SIP registrar?
- Do you agree that the diameter shall only store the URI of a SIP registrar?

If "yes" is the answer to both questions, would it be better to simplify the text as follow:

"The MAR command may also register the SIP server's own URI to the Diameter server, so that future LIR/LIA messages can return this URI.
The Diameter client of a SIP server acting as a SIP registrar MUST include a SIP-Server-URI AVP in the MAR command. In any other case, the SIP-Server-URI AVP MUST NOT be present in the MAR command."

But I may miss some specific configuration cases. If it is the case, sorry for that and forget my proposal!

BR,

Lionel

> -----Message d'origine-----
> De : Miguel Garcia [mailto:[email-masked]] 
> Envoyé : mardi 14 novembre 2006 14:00
> À : AAA mailing list; [email-masked]
> Cc : Mari Carmen belinchon; Miguel-Angel Pallares; Carolina 
> Canales (ML/EEM)
> Objet : [Dime] Diameter SIP app in AUTH48 state
> 
> My apologies for cross posting to both Dime and AAA.
> 
> The Diameter SIP application is in AUTH48 state. The authors 
> have gone through one more review of the document, and found 
> an issue that requires your review and comments. So please 
> review the issue and comment (both agreements and complaints).
> 
> Issue 4: The Diameter server must store the SIP server URI 
> received in the MAR message and return it in the UAA and LIA 
> messages. However the MAR can be either related to stateless 
> proxy authentication (figure 4) or to UA authentication where 
> the proxy remains as main SIP server and in the path for 
> signaling (figure 2 and 3). We don't want that in a mix 
> scenario a stateless SIP proxy request authentication and 
> overrides with its own URI the SIP server assignment in the 
> Diameter server. So we need a mechanism for the Diameter 
> server to distinguish to which scenario the MAR is related 
> and whether it has to store a SIP server or not.
> 
> Our proposal is that the MAR contains a SIP-Server AVP 
> depending on whether the SIP server is stateful and pretends 
> to remain in the signaling path.
> 
> So please comment on this proposal to modify Section 8.7, 2nd 
> paragraph.
> 
> Replace OLD:
> The MAR command also registers the SIP server's own URI to 
> the Diameter server, so that future LIR/LIA messages can 
> return this URI.
> 
> With NEW:
> The MAR command also registers the SIP server's own URI to 
> the Diameter server, so that future LIR/LIA messages can 
> return this URI.
> In scenarios where a SIP server (Diameter client) does not 
> intend to remain in the signaling path as the main SIP server 
> for that user, such as the scenario presented in Section 6.4, 
> the Diameter client (SIP server) MUST NOT include a 
> SIP-Server-URI AVP in the MAR message. In scenarios where a 
> SIP server (Diameter client) intends to remain in the 
> signaling path as the main SIP server for that user, such as 
> the scenarios presented in Sections 6.2 and 6.3, the Diameter 
> Client (SIP server) MUST include its own SIP URI in the 
> SIP-Server-URI AVP in the MAR message.
> 
> 
> For your convenience, the latest version of the draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-si
> p-app-12.txt
> 
> 
> BR,
> 
>      Miguel
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> sip:[email-masked]
> Nokia Research Center      Helsinki, Finland
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
> 

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 14 Nov 2006 17:27:23 +0200

Hi Lionel:

I think you are correct. I am fine with your improved wording.

/Miguel