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

From: "Dikla Dror" <[email-masked]>
Date: Thu, 16 Aug 2007 14:09:37 +0300

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 22 Aug 2007 14:22:14 +0300

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 
> I would appreciate any feedback to the following issue (I’ve turned my 
> A                                                          B
> |                                                           |
> |                                                           |
> |                                                           |
> |                                                           |
>                                                             And so on…
> its local urn (A’s urn). However A doesn’t know yet B’s urn, thus it 
> (B1). This (3) INVITE includes B’s urn.
> 
>  
> 
> relation between B’s urn and the first INVITE (1). Thus, A will maintain 
> ------------------------------------------------------------------------
>

---

From: "Asher Shiratzky" <[email-masked]>
Date: Wed, 22 Aug 2007 14:31:59 +0300

Simplicity is very important, but what will happened in cases where
there is INVITE without registration like emergency calls?

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

Hi,

Cheers,

Gonzalo

>                                                 |               (2)
200 

>                                                             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:
> 
> will maintain only one compartment (B1). This will lead to 
> inconsistency within the SigComp mechanism.
> 
>  
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 22 Aug 2007 14:37:24 +0300

Hi,

the consensus was to require registrations, with all the pros and cons 
associated with that decision.

Cheers,

Gonzalo

---

From: "Dikla Dror" <[email-masked]>
Date: Wed, 22 Aug 2007 14:37:50 +0300

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:[email-masked]] 
Sent: Wednesday, August 22, 2007 2:22 PM
To: Dikla Dror
Cc: [email-masked]
Subject: Re: [rohc] Query about draft-ietf-rohc-sigcomp-sip-07

Hi,

Cheers,

Gonzalo

200 

on...
> As you can see endpoint A is sending an INVITE (1) toward B,
specifying 
> will maintain only one compartment (B1). This will lead to
inconsistency

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 22 Aug 2007 14:50:50 +0300

Hi,

the text you are referring to simply says that that is out of the scope 
of this draft. If you think that supporting that is important, you can 
write an additional specification.

Cheers,

Gonzalo