[sip-comm-dev] when the rfc is a bad boy


#1

Hey all, I'm back with a very nice story :slight_smile:

Once upon a time, in a far away and dangerous sea called sea Mple, there was two contacts: Jack (Sparrow) and Georges (Bush).
Georges wanted to have some news of Jack so he subscribed to him, Jack accepted the subscription and sent some news. Once the news received Georges, who is a very busy man, sent a carrier pigeon to Jack saying that he wants to unsubscribe. Sadly a badly configured server was hunting this day and killed the pigeon: Jack never received the unsubscribe message.
Few minutes later Georges wanted to have some news (again) of Jack so he tried to subscribe again to Jack.
Jack received the subscription and have two choices :

- follow the recommendations of the supreme court (the RFCs) and refuse the new subscription meaning that Georges won't be able to subscribe to him until the first subscription expires (approximately one hour) or until Jack discovers that the subscription is closed by sending to Georges a new state using the closed subscription.

- close the first subscription of Georges and accept the new subscription as if it was a brand new subscription. Knowing that this behavior is still valid considering the expectations of the supreme court but doesn't follows the default recommendations.

What should Jack do ?

Ben :slight_smile:

路路路

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Choice 3: Impeach Georges.

聽聽Because Georges will keep sending whatever damn instructions he
pleases, regardless of RFC, catastrophic failures, or what Georges says
he's sending. Besides, Georges has himself killed so many thousands of
pigeons, badly configured servers, and Jacks, that none of those will
ever work for him again, though Georges is trying to send them all to
pirate on the sea next door.

聽聽Sorry for the diversion, but I've got my priorities.

路路路

On Thu, 2007-07-26 at 11:26 +0200, Benoit Pradelle wrote:

Hey all, I'm back with a very nice story :slight_smile:

Once upon a time, in a far away and dangerous sea called sea Mple, there
was two contacts: Jack (Sparrow) and Georges (Bush).
Georges wanted to have some news of Jack so he subscribed to him, Jack
accepted the subscription and sent some news. Once the news received
Georges, who is a very busy man, sent a carrier pigeon to Jack saying
that he wants to unsubscribe. Sadly a badly configured server was
hunting this day and killed the pigeon: Jack never received the
unsubscribe message.
Few minutes later Georges wanted to have some news (again) of Jack so he
tried to subscribe again to Jack.
Jack received the subscription and have two choices :

- follow the recommendations of the supreme court (the RFCs) and refuse
the new subscription meaning that Georges won't be able to subscribe to
him until the first subscription expires (approximately one hour) or
until Jack discovers that the subscription is closed by sending to
Georges a new state using the closed subscription.

- close the first subscription of Georges and accept the new
subscription as if it was a brand new subscription. Knowing that this
behavior is still valid considering the expectations of the supreme
court but doesn't follows the default recommendations.

What should Jack do ?

Ben :slight_smile:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Ben,

nice story :wink:
One question - in the second case, what happens if the "unsubscription" request (the pigeon) finds its way to the server (Jack) after the client (Georges) has sent his second subscription request, thus closing the both of them ?

Alex

路路路

Le 26 juil. 07 脿 11:26, Benoit Pradelle a 茅crit :

Hey all, I'm back with a very nice story :slight_smile:

Once upon a time, in a far away and dangerous sea called sea Mple, there was two contacts: Jack (Sparrow) and Georges (Bush).
Georges wanted to have some news of Jack so he subscribed to him, Jack accepted the subscription and sent some news. Once the news received Georges, who is a very busy man, sent a carrier pigeon to Jack saying that he wants to unsubscribe. Sadly a badly configured server was hunting this day and killed the pigeon: Jack never received the unsubscribe message.
Few minutes later Georges wanted to have some news (again) of Jack so he tried to subscribe again to Jack.
Jack received the subscription and have two choices :

- follow the recommendations of the supreme court (the RFCs) and refuse the new subscription meaning that Georges won't be able to subscribe to him until the first subscription expires (approximately one hour) or until Jack discovers that the subscription is closed by sending to Georges a new state using the closed subscription.

- close the first subscription of Georges and accept the new subscription as if it was a brand new subscription. Knowing that this behavior is still valid considering the expectations of the supreme court but doesn't follows the default recommendations.

What should Jack do ?

Ben :slight_smile:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Although I'm totally unfamiliar with the matter at hand (SIMPLE, isn't
it? :D) I'd go for the second alternative. It's the most natural and
looks like it deals in a nicer way with the imperfections of the
networks :slight_smile:

Cheers,
Mihai

路路路

On 7/26/07, Benoit Pradelle <ze_real_neo@yahoo.fr> wrote:

Hey all, I'm back with a very nice story :slight_smile:

Once upon a time, in a far away and dangerous sea called sea Mple, there
was two contacts: Jack (Sparrow) and Georges (Bush).
Georges wanted to have some news of Jack so he subscribed to him, Jack
accepted the subscription and sent some news. Once the news received
Georges, who is a very busy man, sent a carrier pigeon to Jack saying
that he wants to unsubscribe. Sadly a badly configured server was
hunting this day and killed the pigeon: Jack never received the
unsubscribe message.
Few minutes later Georges wanted to have some news (again) of Jack so he
tried to subscribe again to Jack.
Jack received the subscription and have two choices :

- follow the recommendations of the supreme court (the RFCs) and refuse
the new subscription meaning that Georges won't be able to subscribe to
him until the first subscription expires (approximately one hour) or
until Jack discovers that the subscription is closed by sending to
Georges a new state using the closed subscription.

- close the first subscription of Georges and accept the new
subscription as if it was a brand new subscription. Knowing that this
behavior is still valid considering the expectations of the supreme
court but doesn't follows the default recommendations.

What should Jack do ?

Ben :slight_smile:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi again Matthew,

I don't think that blocking a client after receiving from him a new subscription is a good idea. In fact what I want to do is the exact opposite: be as available as possible to ensure that we are always able to send our state to anyone interested in receiving it even if there are some problem on the network.

Ben

Matthew Rubenstein a 锟絚rit :

路路路

聽聽Choice 3: Impeach Georges.

聽聽Because Georges will keep sending whatever damn instructions he
pleases, regardless of RFC, catastrophic failures, or what Georges says
he's sending. Besides, Georges has himself killed so many thousands of
pigeons, badly configured servers, and Jacks, that none of those will
ever work for him again, though Georges is trying to send them all to
pirate on the sea next door.

聽聽Sorry for the diversion, but I've got my priorities.

On Thu, 2007-07-26 at 11:26 +0200, Benoit Pradelle wrote:
聽聽

Hey all, I'm back with a very nice story :slight_smile:

Once upon a time, in a far away and dangerous sea called sea Mple, there was two contacts: Jack (Sparrow) and Georges (Bush).
Georges wanted to have some news of Jack so he subscribed to him, Jack accepted the subscription and sent some news. Once the news received Georges, who is a very busy man, sent a carrier pigeon to Jack saying that he wants to unsubscribe. Sadly a badly configured server was hunting this day and killed the pigeon: Jack never received the unsubscribe message.
Few minutes later Georges wanted to have some news (again) of Jack so he tried to subscribe again to Jack.
Jack received the subscription and have two choices :

- follow the recommendations of the supreme court (the RFCs) and refuse the new subscription meaning that Georges won't be able to subscribe to him until the first subscription expires (approximately one hour) or until Jack discovers that the subscription is closed by sending to Georges a new state using the closed subscription.

- close the first subscription of Georges and accept the new subscription as if it was a brand new subscription. Knowing that this behavior is still valid considering the expectations of the supreme court but doesn't follows the default recommendations.

What should Jack do ?

Ben :slight_smile:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Of course you're correct. We can't remove a normal user just because
they're abusing bad rules. I should have made that clear in my joke.

聽聽We do need to remove the president of the United States, George Bush
Jr, from his job.

聽聽Sorry about the OT thread.

路路路

On Thu, 2007-07-26 at 17:00 +0200, Benoit Pradelle wrote:

Hi again Matthew,

I don't think that blocking a client after receiving from him a new
subscription is a good idea. In fact what I want to do is the exact
opposite: be as available as possible to ensure that we are always able
to send our state to anyone interested in receiving it even if there are
some problem on the network.

Ben

Matthew Rubenstein a 茅crit :
> Choice 3: Impeach Georges.
>
> Because Georges will keep sending whatever damn instructions he
> pleases, regardless of RFC, catastrophic failures, or what Georges says
> he's sending. Besides, Georges has himself killed so many thousands of
> pigeons, badly configured servers, and Jacks, that none of those will
> ever work for him again, though Georges is trying to send them all to
> pirate on the sea next door.
>
> Sorry for the diversion, but I've got my priorities.
>
>
> On Thu, 2007-07-26 at 11:26 +0200, Benoit Pradelle wrote:
>
>> Hey all, I'm back with a very nice story :slight_smile:
>>
>> Once upon a time, in a far away and dangerous sea called sea Mple, there
>> was two contacts: Jack (Sparrow) and Georges (Bush).
>> Georges wanted to have some news of Jack so he subscribed to him, Jack
>> accepted the subscription and sent some news. Once the news received
>> Georges, who is a very busy man, sent a carrier pigeon to Jack saying
>> that he wants to unsubscribe. Sadly a badly configured server was
>> hunting this day and killed the pigeon: Jack never received the
>> unsubscribe message.
>> Few minutes later Georges wanted to have some news (again) of Jack so he
>> tried to subscribe again to Jack.
>> Jack received the subscription and have two choices :
>>
>> - follow the recommendations of the supreme court (the RFCs) and refuse
>> the new subscription meaning that Georges won't be able to subscribe to
>> him until the first subscription expires (approximately one hour) or
>> until Jack discovers that the subscription is closed by sending to
>> Georges a new state using the closed subscription.
>>
>> - close the first subscription of Georges and accept the new
>> subscription as if it was a brand new subscription. Knowing that this
>> behavior is still valid considering the expectations of the supreme
>> court but doesn't follows the default recommendations.
>>
>> What should Jack do ?
>>
>> Ben :slight_smile:
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi alexander,

Alexander Pelov a 锟絚rit :

Hi Ben,

nice story :wink:

thanks :slight_smile:

One question - in the second case, what happens if the "unsubscription" request (the pigeon) finds its way to the server (Jack) after the client (Georges) has sent his second subscription request, thus closing the both of them ?

hmmm I haven't imagined this...

So with the current implementation effectively, both subscriptions will be closed and sadly both will be closed in a manner indicating to the distant client that he should not try to resubscribe in a near future...

However this case should be very rare and in the facts, if Georges is using sip communicator and I think that it should be similar with other clients, he will resubscribe something like 30 seconds later.

For the moment the only case I encounter is a case where a badly configured server was blocking the unsubscription, there are enough retransmission mechanisms in SIP to ensure that if a packet can be received, it will reach its destination quickly. But yes, theoretically and if the client is trying to unsubscribe and resubscribe in a very short amount of time (few seconds) it may fails this way.

路路路

Alex

Le 26 juil. 07 锟 11:26, Benoit Pradelle a 锟絚rit :

Hey all, I'm back with a very nice story :slight_smile:

Once upon a time, in a far away and dangerous sea called sea Mple, there was two contacts: Jack (Sparrow) and Georges (Bush).
Georges wanted to have some news of Jack so he subscribed to him, Jack accepted the subscription and sent some news. Once the news received Georges, who is a very busy man, sent a carrier pigeon to Jack saying that he wants to unsubscribe. Sadly a badly configured server was hunting this day and killed the pigeon: Jack never received the unsubscribe message.
Few minutes later Georges wanted to have some news (again) of Jack so he tried to subscribe again to Jack.
Jack received the subscription and have two choices :

- follow the recommendations of the supreme court (the RFCs) and refuse the new subscription meaning that Georges won't be able to subscribe to him until the first subscription expires (approximately one hour) or until Jack discovers that the subscription is closed by sending to Georges a new state using the closed subscription.

- close the first subscription of Georges and accept the new subscription as if it was a brand new subscription. Knowing that this behavior is still valid considering the expectations of the supreme court but doesn't follows the default recommendations.

What should Jack do ?

Ben :slight_smile:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi again,

I think that's a bit tricky situation.. I have neither read the RFC nor played with the protocol, so you are in a much better position to judge which of the two behaviors is "better". In my opinion if it is "strongly recommended" or "obligatory" to go with the first case it would be better to comply with this requirement. Otherwise it's up to you, but bear in mind that the problems you have encountered could be relatively isolated (but persistent) cases , and that the authors of the RFC have tried to cover all possible problems when advising a specific kind of behavior.

In two words - it's your call :wink: May the force be with you!

Alex

路路路

Le 26 juil. 07 脿 12:41, Benoit Pradelle a 茅crit :

Hi alexander,

Alexander Pelov a 茅crit :

Hi Ben,

nice story :wink:

thanks :slight_smile:

One question - in the second case, what happens if the "unsubscription" request (the pigeon) finds its way to the server (Jack) after the client (Georges) has sent his second subscription request, thus closing the both of them ?

hmmm I haven't imagined this...

So with the current implementation effectively, both subscriptions will be closed and sadly both will be closed in a manner indicating to the distant client that he should not try to resubscribe in a near future...

However this case should be very rare and in the facts, if Georges is using sip communicator and I think that it should be similar with other clients, he will resubscribe something like 30 seconds later.

For the moment the only case I encounter is a case where a badly configured server was blocking the unsubscription, there are enough retransmission mechanisms in SIP to ensure that if a packet can be received, it will reach its destination quickly. But yes, theoretically and if the client is trying to unsubscribe and resubscribe in a very short amount of time (few seconds) it may fails this way.

Alex

Le 26 juil. 07 脿 11:26, Benoit Pradelle a 茅crit :

Hey all, I'm back with a very nice story :slight_smile:

Once upon a time, in a far away and dangerous sea called sea Mple, there was two contacts: Jack (Sparrow) and Georges (Bush).
Georges wanted to have some news of Jack so he subscribed to him, Jack accepted the subscription and sent some news. Once the news received Georges, who is a very busy man, sent a carrier pigeon to Jack saying that he wants to unsubscribe. Sadly a badly configured server was hunting this day and killed the pigeon: Jack never received the unsubscribe message.
Few minutes later Georges wanted to have some news (again) of Jack so he tried to subscribe again to Jack.
Jack received the subscription and have two choices :

- follow the recommendations of the supreme court (the RFCs) and refuse the new subscription meaning that Georges won't be able to subscribe to him until the first subscription expires (approximately one hour) or until Jack discovers that the subscription is closed by sending to Georges a new state using the closed subscription.

- close the first subscription of Georges and accept the new subscription as if it was a brand new subscription. Knowing that this behavior is still valid considering the expectations of the supreme court but doesn't follows the default recommendations.

What should Jack do ?

Ben :slight_smile:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net