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

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



Hi,

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

Cheers,

Gonzalo


Asher Shiratzky wrote:
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: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




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