[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [rohc] Query about draft-ietf-rohc-sigcomp-sip-07



Hi,
Thanks for your reply. I have a further question:
There might be applications, which do not handle registrations; the new
draft refers these applications as well, see chapter 9.3: "Note that
linking the lifetime of SIP/SigComp compartments to registration state
limits the applicability of this specification. In particular, SIP user
agents that do not register but, for example, only handle PUBLISH or
SUBSCRIBE/NOTIFY transactions are not able create SIP/SigComp
compartments following this       specification."
How will these applications maintain SigComp compartments? I think the
draft should deal with this issue. 

Thanks,
Dikla. 

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo at ericsson.com] 
Sent: Wednesday, August 22, 2007 2:22 PM
To: Dikla Dror
Cc: rohc at ietf.org
Subject: Re: [rohc] Query about draft-ietf-rohc-sigcomp-sip-07

Hi,

previous versions of the draft addressed this type of on-the-fly 
compartment creation. However, the agreement was to go for a simpler 
solution that requires registrations. Therefore, the compartments would 
have been created at registration time, not when A and B start 
exchanging INVITEs.

Cheers,

Gonzalo

Dikla Dror wrote:
> Hi,
> 
> I've sent a question concerning chapter 9 in 
> draft-ietf-rohc-sigcomp-sip-07 few weeks ago, but got no answer yet.
> 
> I would appreciate any feedback to the following issue (I've turned my

> question into a simpler scenario):
> 
>  
> 
> According to chapter 9, I might encounter imbalanced compartments at 2

> different communicating endpoints in the following scenario:
> 
>  
> 
> This scenario includes 2 endpoints (A, B), communicating over TCP.
> 
>  
> 
>                                                 
> A                                                          B
> 
>                                                 |              (1)

> INVITE                          |
> 
>           Create Compartment (A1) 
> |--------------------------------------------------------->| Create 
> Compartment (B1)
> 
>                                                 
> |                                                           |
> 
>                                                 |               (2)
200 
> OK                             |
> 
>                                                 
> |<---------------------------------------------------------| Use 
> Compartment (B1)
> 
>                                                 
> |                                                           |
> 
>                                                 |              (3)

> INVITE                          |
> 
>           Create Compartment (A2) 
> |<---------------------------------------------------------| Use 
> Compartment (B1)
> 
>                                                 
> |                                                           |
> 
>                                                 
> |                                                           |
> 
>                                                             And so
on...
> 
>            
> 
> As you can see endpoint A is sending an INVITE (1) toward B,
specifying 
> its local urn (A's urn). However A doesn't know yet B's urn, thus it 
> creates a local compartment (A1), related to the INVITE outgoing 
> connection.
> 
> Now B:
> 
> -          Responds the first INVITE with 200 OK (2), related to 
> compartment (B1)
> 
> -          Sends an outgoing INVITE (3) to A, related to compartment 
> (B1). This (3) INVITE includes B's urn.
> 
>  
> 
> However, upon receiving (3) INVITE, endpoint A is not aware of the 
> relation between B's urn and the first INVITE (1). Thus, A will
maintain 
> 2 different compartments - (A1) and (A2) for these 2 sessions while B 
> will maintain only one compartment (B1). This will lead to
inconsistency 
> within the SigComp mechanism.
> 
>  
> 
>  How can I solve this asymmetry according to the draft?
> 
>  
> 
> Thanks,
> 
> Dikla.
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> Rohc mailing list
> Rohc at ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc



_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc