[sip-comm-dev] Adapted no-registrar patch issue


#1

Hello all,

I've tried to go on with the debugging of the adapted no-registrar patch.
The problem I'm focused on is to allow both no-registrar and registrar
mode accounts to be created and loaded at the same time. For now the patch doesn't work (always) for both type of accounts loaded simultaneously.

To describe it very shortly, the idea in Michael Koch's older patch was to
"split" the ProtocolProviderServiceSipImpl class into a registrar mode one
and a no-registrar mode one, both derived from a common functionality
AbstractProtocolProviderServiceSipImpl class. The decision on which one
to instantiate for a specific account depends on a property of the
account. This is checked at account loading in
ProtocolProviderFactorySipImpl.

The problem now is that, when a no-registrar account and also a registrar
one are loaded, when receiving a call addressed to the no-registrar
account, the provider processing the request happens to be the one for the
registrar mode account. This doesn't happen in every case (see below) but
it does happen even if the only logged in account is the no-registrar one (actually this is the use case I'm testing now, one registrar mode account and one no-registrar mode only with the no-registrar mode logged in - same configuration for both peers in the test)

I've tried to debug the issue since the weekend repeatedly tracking back
function calls to see where does the problem appear. What I can tell is that the two accounts seem to be loaded correctly and the bundle registration of the specific ProtocolProviderService is done right.
Like I said, when the wrong provider processes the request, it is selected as the call would have been addressed to the registrar mode account, not because the wrong type of service provider was registered for the no-registrar account. The OperationSetBasicTelephonySipImpl from which the processRequest is called in the end corresponds to the registrar account (as the protocol provider service does too). However, the INVITE received seems to be on correct account id (the no-registrar one).

In essence, until now I didn't found anything going wrong before the actual call. From the function call stack, when an INVITE is received, the first function called from the SC sources is the processRequest in the account's should-be-corresponding protocol service provider. I'm not exactly sure how the specific provider is selected to process the request and this was my initial question. Anyway, I decided to go deeper before asking, and I went with the function calls tracking into the JAIN SIP stack (I'm not sure I've got the right version sources but binding the ones I got to the debugger, at least for this part, seems to be ok). According to the function call stack, the last function before the processRequest in the protocol service provider is the deliverEvent one from the EventScanner (actually at this level of tracking back I've checked the INVITE too). What I can see here is that the sip stack used is again the wrong one, so the cause of the faulty provider selection seems to be even deeper. I'm not sure if I'm correct about this debugging direction, so I've stopped here (also because at least for the specific thread the function call stack doesn't go much deeper - starts with Thread.run() , EventScanner.run() so deeper tracing back would probably mean to search in the JAIN SIP stack sources for the location where the EventScanner is instantiated).

The only thing that's clear for now (if I may say so...) is that the wrong protocol provider selection for handling a call isn't a permanent behavior. I repeatedly deleted and created test accounts for the specified use case configuration until all went fine. So, there are cases of accounts that seem "to support" the patch, and cases of accounts which doesn't support the patch. I didn't observe any difference during stepping through the code (at least first) so I finally decided to take a "incorrectly behaving" case sip-communicator.xml and make changes by copy pasting the info from a "correctly behaving" one until I can find what's the difference which causes all the problem. As weird or stupid it might sound is the registrar mode account's random generated (I think..) tag value. I reproduce two cases next :

- correct behaviour (right protocol provider service selection - modified xml):

  <acc1215995650593 value="acc1215995650593"> -> for registrar mode account
  <acc1216123156015 value="acc1216123156015"> -> for no-registrar mode account

- incorrect behaviour (wrong protocol provider service selection - original xml):

  <acc1216123126656 value="acc1216123126656"> -> for registrar mode account
  <acc1216123156015 value="acc1216123156015"> -> for no-registrar mode account (same as above)

( in the source for the modified xml - correct behavior case, the tag was taken from another correct behaviour one which looked like this:

  <acc1215995650593 value="acc1215995650593"> -> registrar
  <acc1216029733750 value="acc1216029733750"> -> no-registrar )

Well, after this "discovery" I traced again the code with more attention on the account loading. There is a difference between the "correct" and the "incorrect" case: in the correct case the no-registrar account is loaded first, in the incorrect case the registrar account is loaded first. I can't find any explanation directly related with the values above because in both the cases the registrar one is lower, but this is after all irrelevant due to possible order difference change after some hashing (not sure though). Anyway, this account loading order is the only difference I found like I said, and doesn't seem to cause any other problem. Both types of service providers are registered. I even tried to "reverse" the use case for the correct behaviour xml version for which the no-registrar account is used first. I tested with the registrar accounts logged on, the no-registrar logged off, to see if the selected provider isn't wrong this time in the opposite way - selecting only the no-registrar provider. The call went fine. Off course it's not really complete opposite conditions because this time the registrar SIP server was started and used.

These are, I think, the most important facts observed. In the end I might say that I'm pretty puzzled after few days of debugging. My opinion is that it might be after all something related with the account loading order, or if not (and this is worse) something deeper inside the JAIN SIP stack. There is also a third posibility (which probably I should have considered from start...) that some parts of the adapted code indirectly may cause this due to various other changes between the original sources that were patched and the ones from now. I still didn't review one more time all the parts I've adapted, so it's possible to have missed something. I'll eventually compare an older trunk revision I've checked out, which was the subject of the original patch, with the current sources to see if I can get a solution. However, the "root" of the bug, if I may say so, is after all the way the wrong service provider gets selected instead of the right one. From the debugging described I can't figure out how, or were in the code this happens. (I really doubt that it is in the rest of patch, but like I said any not enough reviewed sections or other older-newer source differences might trigger it indirectly). I'm really unexperienced with the way the JAIN SIP stack works ( and also many other parts discussed above :slight_smile: ), so any opinion about where/how this protocol provider service/wrong sip stack selection happens, or about any of the facts described is more than welcome.

Regards,
Emanuel

PS: In the latest patch submitted the instantiation of registrar mode providers was disabled inside the code. To get it running (if someone wants to test the faulty patch) just modify inside the ProtocolProviderFactorySipImpl the line:

if (accountProperties.containsKey(NO_REGISTRAR))

with

if (Boolean.valueOf((String)accountProperties.get(NO_REGISTRAR)))

···

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

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


#2

Hello all,

I'll focus on the first part on a minor Hold issue encountered because it might be also of Werner's interest for the ZRTP branch patch, and go on in detail next with the no-registrar patch issue, for which some opinions would be very helpful.

(I'll pretty much copy paste the info from my last GSoC blog dev entry, so for anyone who already read it it's quite the same)

I've merged the encryption branch with the latest main trunk revision and I solved the conflicts, but I didn't committed it yet. I found a minor bug related with the new Hold feature.

The bug manifests the next way: When I put a call on hold, after I release it in aproximately 20 seconds the call ends abruptly without any error message in the console. The logger displays only the warning message from the callStateChanged function inside the CallSessionImpl class : "Stopping streaming." like a CALL_ENDED event was received. I didn't debug the code further because I tested this also in no-registrar mode and it seems it doesn't happen, so it's very posssible to be related with the type of registrar used (Brekeke SIP Server). However I didn't commit the merge to the encryption branch yet, as I said; I wonder if putting the call on Hold doesn't affect somehow the ZRTP integration at some level and I must take a careful look at it (at a first sight the ZRTP exchange shouldn't be affected at least, but the first thought when encountering the bug above was that is related with the RTPConnector usage for handling the media flow in the ZRTP integration branch; anyway it also occurs between two peers built from main trunk when using my registrar so it seems it wasn't that).

The idea in order to end with this part, is that the latest merge with the main trunk for the no-encryption branch is available for now only attached to this mail (last-rev-merge-patch) and from a link on my GSoC blog.

Now, related to the no-registrar patch, I think the last mail I've sent related to the problem was a bit over-detailed and I'll try to summarize it trough a hopefully more clear example of test/use case on which I'll add some new observations I found out after more debugging done.

Let's take this as a use/test case:

We have two SC peers.
Peer A has three accounts created: one registrar mode account R1 and two no-registrar mode accounts: NR1 and NR3.
Peer B has two accounts created: one registrar mode account R2 and one no-registrar mode account NR2.

The registrar server is shut down.
Peer A has NR1 logged in.
Peer B has NR2 logged in.

Peer B (NR2) calls Peer A (NR1) - the INVITE is sent on NR1@w.x.y.z (where w.x.y.z is Peer A's IP address).

The problem: The INVITE request is processed by the SIP stack instantiated by the R1 - not NR1 - account's Protocol Service Provider (which is a registrar-mode type). The stack is of course also the one which continues the call handling, which makes the wrong ProtocolProviderService to process any further requests.

What I can tell for sure after the debugging done last week: The reason why R1's ProtocolProviderService's SIP stack is the one which handles the INVITE request, is the fact that in this specific test case the R1 account is the one that's loaded first (which also means that the corresponding Protocol Provider Service is the first one from the three registered in the bundle context). The account loading order might differ. After deleting and re-creating all the accounts, the first account loaded was NR3 for example and the SIP stack/ProtocolProviderService handling the INVITE addressed to NR1 were the one associated with NR3.

I tried also other configurations; all lead to the same conclusion - the first loaded account's ProtocolProviderService registered is the one which handles the requests when operating in no-registrar mode - it doesn't matter if the first loaded account it's registrar mode or not, if it's logged in or not or if the request is addressed to a totally different target.

I couldn't find why this happens. I managed to trace the code back into the JAIN SIP RI sources, up to inside the SipTransactionStack class but this doesn't help me. The stack is of course the one corresponding to the first loaded account. What I need to know is the point where the code gets there - how the stack/ProtocolProviderService is selected to handle the request. The getProviderForAccount and getRegisteredAccounts inside the ProtocolProviderFactorySipImpl don't seem to have anything to do with this, being called only prior to the call initiation, in the account loading phase, and I didn't find any bug there. Some more details and also about another test case also can be found inside the mail I've sent last week (you can find it at the end of this one).

After a lot of debugging done and no success, I decided to check out the revision which was the initial subject for the original patch by Michael Koch - revision 3252, to see what makes the difference. I applied the original patch, activated the no registrar Protocol Provider Service instantiation, and unfotunately there isn't any difference - the same problem is present.

This happens however when the registrar is off. When the registrar is on the calls routed trough it, addressed to registrar mode accounts, reach their target ProtocolServiceProvider successfully.

Anyway, even if I couldn't find out what causes the problem, I made some "fixes" to the initial patch submitted:

- added the OperationSetTypingNotifications to the others in the registrar mode ProtocolProviderService
- cut out the REGISTERS_USE_ROUTE property from the AbstractProtocolProviderServiceSipImpl (it was a duplicate - also in the registrar mode provider service)
- restricted the entire keep alive related functionality only to registrar mode ProtocolProviderService instantiations (I'm not very sure about this but at least the using of REGISTER for keep alive in non-registrar mode doesn't seem to make sense; though I'm not entirely sure about OPTIONS request - I'm not very experienced with SIP; anyway, it was a newer functionality added since the initial patch and I've done the modification also to exclude a potential source for the bug .. but it wasn't)
- added an if branch in the new sayBye method from the OperationsSetBasicTelephonySipImpl for specific cases of registrar or no-registrar mode provider service (again I'm not entirely certain about if that is correct or not):

ArrayList viaHeaders;
// complete via headers according to the provider type
if (protocolProvider.getClass()
     .equals(ProtocolProviderServiceSipImpl.class))
     {
         viaHeaders = protocolProvider.getLocalViaHeaders(
               destinationInetAddress,
               ((ProtocolProviderServiceSipImpl)protocolProvider)
               .getRegistrarConnection().getRegistrarListeningPoint());
     }
     else
     {
         viaHeaders= protocolProvider.getLocalViaHeaders(
               destinationInetAddress,
     protocolProvider.getDefaultListeningPoint());
     }

These, together with other older and more minor modifications can be found in the patch attached to this mail (current-rev-no-registrar) or on a link on my dev blog.

Note that this patch allows ProtocolProviderService instantiation for registrar and no-registrar mode also. The older patches had the registrar mode option blocked allowing only no-registrar. Even if the mentioned problem was present also at that time, the call, because being handled through a no-registrar ProtocolProviderService as it was intended, went on fine.

I've already spent a week with the debugging and I didn't manage to solve the main bug, so I'll wait that hopefully somebody more experienced with SIP or with the JAIN stack can give me some feedback on the issue presented, before I try to go further.

I'm going back for now to my main GSoC project theme.

Regards,
Emanuel

current-rev-no-registrar.patch (232 KB)

last-rev-merge-patch.patch (997 KB)

···

On Wed, 16 Jul 2008, Onica S. Emanuel wrote:

Hello all,

I've tried to go on with the debugging of the adapted no-registrar patch.
The problem I'm focused on is to allow both no-registrar and registrar
mode accounts to be created and loaded at the same time. For now the patch doesn't work (always) for both type of accounts loaded simultaneously.

To describe it very shortly, the idea in Michael Koch's older patch was to
"split" the ProtocolProviderServiceSipImpl class into a registrar mode one
and a no-registrar mode one, both derived from a common functionality
AbstractProtocolProviderServiceSipImpl class. The decision on which one
to instantiate for a specific account depends on a property of the
account. This is checked at account loading in
ProtocolProviderFactorySipImpl.

The problem now is that, when a no-registrar account and also a registrar
one are loaded, when receiving a call addressed to the no-registrar
account, the provider processing the request happens to be the one for the
registrar mode account. This doesn't happen in every case (see below) but
it does happen even if the only logged in account is the no-registrar one (actually this is the use case I'm testing now, one registrar mode account and one no-registrar mode only with the no-registrar mode logged in - same configuration for both peers in the test)

I've tried to debug the issue since the weekend repeatedly tracking back
function calls to see where does the problem appear. What I can tell is that the two accounts seem to be loaded correctly and the bundle registration of the specific ProtocolProviderService is done right.
Like I said, when the wrong provider processes the request, it is selected as the call would have been addressed to the registrar mode account, not because the wrong type of service provider was registered for the no-registrar account. The OperationSetBasicTelephonySipImpl from which the processRequest is called in the end corresponds to the registrar account (as the protocol provider service does too). However, the INVITE received seems to be on correct account id (the no-registrar one).

In essence, until now I didn't found anything going wrong before the actual call. From the function call stack, when an INVITE is received, the first function called from the SC sources is the processRequest in the account's should-be-corresponding protocol service provider. I'm not exactly sure how the specific provider is selected to process the request and this was my initial question. Anyway, I decided to go deeper before asking, and I went with the function calls tracking into the JAIN SIP stack (I'm not sure I've got the right version sources but binding the ones I got to the debugger, at least for this part, seems to be ok). According to the function call stack, the last function before the processRequest in the protocol service provider is the deliverEvent one from the EventScanner (actually at this level of tracking back I've checked the INVITE too). What I can see here is that the sip stack used is again the wrong one, so the cause of the faulty provider selection seems to be even deeper. I'm not sure if I'm correct about this debugging direction, so I've stopped here (also because at least for the specific thread the function call stack doesn't go much deeper - starts with Thread.run() , EventScanner.run() so deeper tracing back would probably mean to search in the JAIN SIP stack sources for the location where the EventScanner is instantiated).

The only thing that's clear for now (if I may say so...) is that the wrong protocol provider selection for handling a call isn't a permanent behavior. I repeatedly deleted and created test accounts for the specified use case configuration until all went fine. So, there are cases of accounts that seem "to support" the patch, and cases of accounts which doesn't support the patch. I didn't observe any difference during stepping through the code (at least first) so I finally decided to take a "incorrectly behaving" case sip-communicator.xml and make changes by copy pasting the info from a "correctly behaving" one until I can find what's the difference which causes all the problem. As weird or stupid it might sound is the registrar mode account's random generated (I think..) tag value. I reproduce two cases next :

- correct behaviour (right protocol provider service selection - modified xml):

<acc1215995650593 value="acc1215995650593"> -> for registrar mode account
<acc1216123156015 value="acc1216123156015"> -> for no-registrar mode account

- incorrect behaviour (wrong protocol provider service selection - original xml):

<acc1216123126656 value="acc1216123126656"> -> for registrar mode account
<acc1216123156015 value="acc1216123156015"> -> for no-registrar mode account (same as above)

( in the source for the modified xml - correct behavior case, the tag was taken from another correct behaviour one which looked like this:

<acc1215995650593 value="acc1215995650593"> -> registrar
<acc1216029733750 value="acc1216029733750"> -> no-registrar )

Well, after this "discovery" I traced again the code with more attention on the account loading. There is a difference between the "correct" and the "incorrect" case: in the correct case the no-registrar account is loaded first, in the incorrect case the registrar account is loaded first. I can't find any explanation directly related with the values above because in both the cases the registrar one is lower, but this is after all irrelevant due to possible order difference change after some hashing (not sure though). Anyway, this account loading order is the only difference I found like I said, and doesn't seem to cause any other problem. Both types of service providers are registered. I even tried to "reverse" the use case for the correct behaviour xml version for which the no-registrar account is used first. I tested with the registrar accounts logged on, the no-registrar logged off, to see if the selected provider isn't wrong this time in the opposite way - selecting only the no-registrar provider. The call went fine. Off course it's not really complete opposite conditions because this time the registrar SIP server was started and used.

These are, I think, the most important facts observed. In the end I might say that I'm pretty puzzled after few days of debugging. My opinion is that it might be after all something related with the account loading order, or if not (and this is worse) something deeper inside the JAIN SIP stack. There is also a third posibility (which probably I should have considered from start...) that some parts of the adapted code indirectly may cause this due to various other changes between the original sources that were patched and the ones from now. I still didn't review one more time all the parts I've adapted, so it's possible to have missed something. I'll eventually compare an older trunk revision I've checked out, which was the subject of the original patch, with the current sources to see if I can get a solution. However, the "root" of the bug, if I may say so, is after all the way the wrong service provider gets selected instead of the right one. From the debugging described I can't figure out how, or were in the code this happens. (I really doubt that it is in the rest of patch, but like I said any not enough reviewed sections or other older-newer source differences might trigger it indirectly). I'm really unexperienced with the way the JAIN SIP stack works ( and also many other parts discussed above :slight_smile: ), so any opinion about where/how this protocol provider service/wrong sip stack selection happens, or about any of the facts described is more than welcome.

Regards,
Emanuel

PS: In the latest patch submitted the instantiation of registrar mode providers was disabled inside the code. To get it running (if someone wants to test the faulty patch) just modify inside the ProtocolProviderFactorySipImpl the line:

if (accountProperties.containsKey(NO_REGISTRAR))

with

if (Boolean.valueOf((String)accountProperties.get(NO_REGISTRAR)))

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."


#3

Hello Emanuel,

The bug manifests the next way: When I put a call on hold, after I release it in aproximately 20 seconds the call ends abruptly without any error message in the console. The logger displays only the warning message from the callStateChanged function inside the CallSessionImpl class : "Stopping streaming." like a CALL_ENDED event was received.

Would you mind testing with the current SC trunk (i.e. without your branch) with your registrar configuration and report here if it also happens?
Note that there were some changes in the Hold related code recently (I think I saw some commits this week), so It might also be a good idea to merge the main trunk with your branch again.

Cheers,

···

On 2008/07/22, at 21:08, Onica S. Emanuel wrote:
--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/

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


#4

Hello,

The initial tests I've ran were on three versions of SC: the encryption branch, the encryption branch with no-registrar and the main trunk last revision only. I've merged again the encryption branch after your mail with the main trunk and redone the test (also without the encryption branch). The problem is the same. However like I said last time it seems it might be related with the registrar I'm using (Brekeke SIP Server), because in no-registrar mode it doesn't appear. The following call function stack caught at the moment where the CALL_ENDED event is received in CallSessionImpl seems to confirm this:

CallSessionImpl.callStateChanged(CallChangeEvent) line: 2115
CallSipImpl(Call).fireCallChangeEvent(String, Object, Object) line: 232
CallSipImpl.setCallState(CallState) line: 113
CallSipImpl.removeCallParticipant(CallParticipantSipImpl) line: 94
CallSipImpl.participantStateChanged(CallParticipantChangeEvent) line: 197
CallParticipantSipImpl(AbstractCallParticipant).fireCallParticipantChangeEvent(String, Object, Object, String) line: 131
CallParticipantSipImpl(AbstractCallParticipant).fireCallParticipantChangeEvent(String, Object, Object) line: 76
CallParticipantSipImpl.setState(CallParticipantState, String) line: 179
OperationSetBasicTelephonySipImpl.processTimeout(TimeoutEvent) line: 1215
ProtocolProviderServiceSipImpl.processTimeout(TimeoutEvent) line: 1121
EventScanner.deliverEvent(EventWrapper) line: 371
EventScanner.run() line: 492 [local variables unavailable]
Thread.run() line: 619 [local variables unavailable]

The request which causes the TimeoutEvent in the processTimeout function from ProtocolProviderServiceSipImpl is an INVITE which looks like this:

INVITE sip:eontest02@w.x.y.z:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 0.0.0.0;branch=z9hG4bK6028fc60c92752a388b13aa6193b1379
CSeq: 1 INVITE
Call-ID: 936d9c68884f95bb0317582128a2b8a5@0.0.0.0

From: "eontest01" <sip:eontest01@w.x.y.z>;tag=45db520a

User-Agent: SIP Communicator 1.0-alpha3-0.build.by.SVN Windows XP
Max-Forwards: 70
Contact: <sip:0.0.0.0:55363;transport=udp>
Route: <sip:w.x.y.z:5060;lr>
Content-Type: application/sdp
Content-Length: 173

(where w.x.y.z is the registrar's IP)

I hope the debug results to be of some use, but like I said it might be exclusively related with my registrar/call configuration; the problem seems to appear mostly (but not exclusively) only in the case of one of the peers placing the call on hold - the one which resides on the same machine with the registrar (which is also the one where the above INVITE is timed out); when the other one puts the call on hold it seems to work well most of the time.

I also redone the tests last week with SC on Windows-Twinkle on Linux after the previous merge. The results are the same as previous ones, meaning ok, with one exception which is again related to placing the call on hold. This seems to cause the crash of the encrypted audio channel (after resuming, Twinkle doesn't report anymore the channel to be secured and in addition the audio stream is lost being replaced by garbled noise). This happens both cases: if Twinkle client places the call on hold or the SC client does that. Anyway, again this probably is a Twinkle-SC incompatibility regarding the hold feature. To be sure all is fine, I've checked in SC-SC case if the packets are encrypted also after placing the call on hold (by the peer on which I've said it usually works). The check results were that the encryption goes well also after resuming from hold.

So, in what concerns the encryption branch the hold doesn't seem to have any negative impact so far (in SC-SC calls), the problem mentioned last time not being related with the ZRTP integration and possible being caused by the registrar or the entire test configuration.

About the other issue in the mail subject - the one related with the no-registrar patch I've checked again the INVITE sent and I can't tell that something is wrong there - all seems to be ok at that point. Even if it's addressed to one specific account the request is processed by the SIP stack corresponding to the first loaded account like I've written previously. I'm not sure what I'm missing, I've detailed the debugging done in the previous mails, but I don't think it's related with the INVITE. However, I'll run another debug and post an INVITE sample as it's sent also on my blog.

Regards,
Emanuel

PS: Sorry for the reply being a bit delayed. Had some technical problems last weekend = a display crash.

···

To: "eontest02" <sip:eontest02@w.x.y.z>;tag=d3c9c209

On Sat, 26 Jul 2008, Romain KUNTZ wrote:

Hello Emanuel,

On 2008/07/22, at 21:08, Onica S. Emanuel wrote:

The bug manifests the next way: When I put a call on hold, after I release it in aproximately 20 seconds the call ends abruptly without any error message in the console. The logger displays only the warning message from the callStateChanged function inside the CallSessionImpl class : "Stopping streaming." like a CALL_ENDED event was received.

Would you mind testing with the current SC trunk (i.e. without your branch) with your registrar configuration and report here if it also happens?
Note that there were some changes in the Hold related code recently (I think I saw some commits this week), so It might also be a good idea to merge the main trunk with your branch again.

Cheers,

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

---------------------------------------------------------------------
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 Emanuel,

The initial tests I've ran were on three versions of SC: the encryption branch, the encryption branch with no-registrar and the main trunk last revision only. [...] The problem is the same.

Ok, then it's better to leave this problem out of your main topic. Once the Hold problem has been solved on the main trunk, we'll check if it works well on the encryption branch.

About the other issue in the mail subject - the one related with the no-registrar patch I've checked again the INVITE sent and I can't tell that something is wrong there - all seems to be ok at that point. Even if it's addressed to one specific account the request is processed by the SIP stack corresponding to the first loaded account like I've written previously. I'm not sure what I'm missing, I've detailed the debugging done in the previous mails, but I don't think it's related with the INVITE. However, I'll run another debug and post an INVITE sample as it's sent also on my blog.

Ok, you can give one more try if you want, but it may also be better to not spend too much time on that if you think that the problem is not directly related to the no-registrar patch. It may be better to add instead an issue in the SC tracker with some details, in order to keep track of the problem.

Cheers,

···

On 2008/07/29, at 21:05, Onica S. Emanuel wrote:
--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/

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